Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Design Patterns

Design Patterns



|Views: 425|Likes:
Published by alokkumaryadav
All Design Patterns information
All Design Patterns information

More info:

Published by: alokkumaryadav on Apr 09, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Time Stays Long Enough For Those Who Will Use It.
 Alok kumar 4/8/2009 1-25
What Are Design Patterns and Do I Need Them?
http://www.developer.com/design/article.php/1474561 ByJames Maioriello 
Software professionals may be familiar with the term "Design Patterns," but many haveno idea of where they come from and what they truly are. Consequently, some do notsee the value and benefits design patterns bring to the software development process,especially in the areas of maintenance and code reuse. This article will bridge this gap bydefining design patterns from a historical perspective. It will also summarize the salientfeatures of a typical design pattern and arrive at a working definition so that you willknow what they are and what to expect when you incorporate them into your designs.Finally, it will explicitly summarize the benefits design patterns bring to softwaredevelopment and why you should incorporate them into your work. Subsequent articleswill present more detailed descriptions of some of the more common design patterns,and how they can be applied to software development on the .NET platform.
What Are Design Patterns and Where Do They Come From?
Design patterns are commonly defined as time-tested solutions to recurring designproblems. The term refers to both the description of a solution that you can read, and aninstance of that solution as used to solve a particular problem. (I like the analogy of comparing design patterns to a class and an object instance of the class. Each is adifferent way to represent a thing.) Design patterns have their roots in the work of Christopher Alexander, a civil engineer who wrote about his experience in solving designissues as they related to buildings and towns. It occurred to Alexander that certaindesign constructs, when used time and time again, lead to the desired effect. Hedocumented and published the wisdom and experience he gained so that others couldbenefit. About 15 years ago, software professionals began to incorporate Alexander'sprinciples into the creation of early design pattern documentation as a guide to novicedevelopers. This early work led others to also write about design patterns and culminatedin the publication of 
Design Patterns: Elements of Reusable Object-Oriented Software
in1995 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. This book isconsidered to be the "coming out" of design patterns to the software community at largeand has been influential in the evolution of design patterns since.
Design Patterns
 described 23 patterns that were based on the experience of the authors at that time.These patterns were selected because they represented solutions to common problems insoftware development. Many more patterns have been documented and cataloged sincethe publishing of 
Design Patterns
. However, these 23 are probably the best known andcertainly the most popular.Design patterns are represented as relationships between classes and objects withdefined responsibilities that act in concert to carry out the solution. To illustrate a designpattern, consider the Adapter pattern, one of the original 23 patterns described in
. Adapter provides a solution to the scenario in which a client and server need tointeract with one another, but cannot because their interfaces are incompatible. Toimplement an Adapter, you create a custom class that honors the interface provided bythe server and defines the server operations in terms the client expects. This is a muchbetter solution than altering the client to match the interface of the server.The design pattern community is growing both in membership and coverage. The patternliterature describes new patterns that solve emerging issues related to technicaladvancements. As a software professional, you are the beneficiary of this body of knowledge. To use these patterns, you will need to learn them and become familiar with
Time Stays Long Enough For Those Who Will Use It.
 Alok kumar 4/8/2009 2-25
them so you will know which pattern to pull from your toolbox when a design issuearises. Many patterns have been documented over the years. They have been classifiedin different ways by different authors. Take the time to learn different ways to classifydesign patterns because you will gain greater insight into them. As you learn more andmore patterns, it would be a good idea to develop your own classification system; onereflecting the way you utilize them.
Structure of a Design Pattern
Design pattern documentation is highly structured. The patterns are documented from atemplate that identifies the information needed to understand the software problem andthe solution in terms of the relationships between the classes and objects necessary toimplement the solution. There is no uniform agreement within the design patterncommunity on how to describe a pattern template. Different authors prefer differentstyles for their pattern templates. Some authors prefer to be more expressive and lessstructured, while others prefer their pattern templates to be more precise and high grainin structure. We will use the template first described by the authors of 
Design Patterns
toillustrate a template.
 Pattern Name Describes the essence of the pattern in a short, but expressive, nameIntent Describes what the pattern doesAlso KnownAsList any synonyms for the patternMotivation Provides an example of a problem and how the pattern solves that problemApplicability Lists the situations where the pattern is applicableStructure Set of diagrams of the classes and objects that depict the patternParticipants Describes the classes and objects that participate in the design pattern andtheir responsibilitiesCollaborations Describes how the participants collaborate to carry out their responsibilitiesConsequences Describes the forces that exist with the pattern and the benefits, trade-offs,and the variable that is isolated by the pattern
This template captures the essential information required to understand the essence of the problem and the structure of the solution. Many pattern templates have lessstructure than this, but basically cover the same content.
Benefits of Design Patterns
Design patterns have two major benefits. First, they provide you with a way to solveissues related to software development using a proven solution. The solution facilitatesthe development of highly cohesive modules with minimal coupling. They isolate thevariability that may exist in the system requirements, making the overall system easierto understand and maintain. Second, design patterns make communication betweendesigners more efficient. Software professionals can immediately picture the high-leveldesign in their heads when they refer the name of the pattern used to solve a particularissue when discussing system design.
Time Stays Long Enough For Those Who Will Use It.
 Alok kumar 4/8/2009 3-25
James Maioriello, Ph.D.
, is a Senior Design Engineer for Formation Systems Inc., acorporation located in Massachusetts dedicated to the development of software systemsfor product development in the processing industries. His position allows him to use hisexpertise and skills to design solutions for chemists and other scientists so they can focustheir talents on innovation. Dr. Maioriello obtained degrees in Chemistry from LehighUniversity and in Software Engineering from Polytechnic University in New York.
A Survey of Common Design Patterns
If you are new to design patterns, studying them can seem like a daunting task. Thenumber and scope of design patterns has been steadily increasing since the publication of 
Design Patterns: Elements of Reusable Object-Oriented Software
, by Erich Gamma,Richard Helm, Ralph Johnson, and John Vlissides in 1995. In their book, they present 23design patterns organized into three categories: 1) Creational, 2) Structural, and 3)Behavioral design patterns. Since then, they and other authors have described otherclassification schemes for these patterns. By examining design patterns within differentclassification strategies, you will give yourself a deeper insight into what they are andhow to use them. As you gain familiarity with them, you can begin to use them in yourprojects. In this paper, we will summarize the 23 common design patterns within thethree categories. It is intended to serve as a glossary that I will refer to in the future.
Abstract Factory
The Abstract Factory is intended to provide a single interface for clients to use when theyneed to create a family of related objects without having to specify concrete classes. Forexample, imagine a system that needs to implement platform-specific user interfaceobjects (menus, toolbars, and so forth) for several different platforms. Abstract Factorysimplifies the interface for the client by localizing all of the initialization strategies withina single class, the Abstract Factory. The pattern works to ensure that all the strategiescan work together correctly.To understand Abstract Factory, examine the class diagram shown in the following figure.Note that there are two separate hierarchies. The first represents the variousabstractions the client has interest in. For each abstraction, there exists an abstract classdefinition (AbstractClass1, AbstractClass2, and so on), and the subclasses that providethe concrete implementations (ConcreteClass1A, ConcreteClass1B, and so forth). In thesecond hierarchy, an abstract AbstractFactory class is defined to provide the interface foreach class that is responsible for creating the members of a particular family. Forexample, ConcreteFactoryB is responsible for creating objects from classesConcreteClass1B, ConcreteClass2B, and the like. All the client needs to worry about iswhich family of objects it is interested in creating and calling the appropriate Factorymethod. Because the client only knows about the abstract interface, it can interact withobjects from different families without having to know about their internalimplementation details. This approach has the benefit that the family can be allowed togrow without the need to modify the client. The primary drawback of AbstractFactory isthat it can limit your flexibility when you want to take advantage of a specific capability afamily may have. This is because you must provide a common interface across allfamilies, even if some of them do not have this capability.

Activity (10)

You've already reviewed this. Edit your review.
1 thousand reads
1 hundred reads
smithwil liked this
Edo Gasparetto liked this
ascentway liked this
Shyam liked this
rahulfriends007 liked this
sonyvishu liked this
konogahri liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->