Design Patterns
Total Page：16
File Type：pdf, Size：1020Kb
Design Patterns Supada Laosooksathit 101-87-765 October 18, 2008 Definition A design pattern is a general reusable solution to a standard reoccurring problem in software design. [1] A design pattern is a description to template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, describe problems and solutions that have alternative scopes. [2] History Design patterns have originated as an architectural concept by Christopher Alexander, a civil engineer who wrote about his experience in solving design issues as they related to buildings and towns. [2, 3] He documented and published the wisdom and experience he gained from his work so that others could benefit. About 15 years ago, software professionals began to incorporate Alexander’s principles into the creation of early design pattern documentation as a guide to novice developers. [3] In 1987, Kent Beck and Ward Cunningham presented the idea of applying patterns to programming at the OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference. In the following years, Beck, Cunningham and others followed up on this work. Since then, many papers and presentations have appeared. [2] Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 by Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. (They are often refered to as the Gang of Four, or GoF.) [2, 4] Pratice and Uses Design patterns can speed up the development process by providing a way to solve issues related to soft- ware development using a proven solution. They provide general solutions documented in a typical format. Reusing design patterns also helps to prevent subtle issues that can cause major problems, and improves code readability for coders and architects familiar with the patterns. [3, 5] Design patterns can make com- munication between designers more efficient with well-known, well-understood names of software interations. [3, 5] 1 Classification Design patterns are classified into the following categories. Creational Patterns Creational patterns are a best way in which class and object can be instantiated. [5, 6] This pattern can be divided into class-creation patterns which use interitance effectively in the instantiation process and object-creational patterns which use delegation effectively to get the job done. [5] • Abstract Factory An abstract factory pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes. [2, 5] It provides a way to encapsulate a group of individual factories that have a common theme. The client software would create a concrete implementation of the abstract factory and use the generic interfaces to create the concrete objects that are part of the theme. The names of actual implementing classes are not needed to be known at the client side. Because this pattern separates the details of implementation of a set of objects from its general usage, the implementation can be changed from one factory to another. [2, 6] • Factory Method A factory method pattern define an interface for creating objects, whose subclasses can override to specify the derived type of product that will be created. It lets subclasses decide which class to instantiate. [2, 5] • Builder A builder pattern intends to separate the construction of a complex object from its representation so that the same construction process can create different representations. It is used to build products in accordance to the Composite Pattern, a Structure Pattern. It parse a complex representation and create on of several targets. [2, 5] • Object Pool An object pool is a set of initialised objects that are kept ready to use, rather than allocated and destroyed on demand. A client of the pool will request an object from the pool and perform operations on the returned object. When the client has finished with an object, it returns the object to the pool, rather than destroying it. It is a specific type of factory object. Object pooling is most effective in situations where the cost of initializing a class instance is high, the rate of instantiation of a class is high, and the number of instances in use at any one time is low. [2, 5] • Prototype A prototype pattern is used to create a clone of an object to avoid creation a new one when the cost of creating a new object is large and creation is resource intensive. To implement the pattern, declare an abstrat base class that specifies a pure virtual clone() method and the client calls the clone() method on the prototype instead of invokeing the new operator. [2, 6] • Singleton A singleton pattern is used to restrict instantiation of a class to one object. This concept is generalized to restrict the instance to specific number of objects and to systems that operate more efficiently when only one or a few objects exist. A ”singleton” simply refers to an object without copies or that is not used as the prototype for any other object. [2] 2 Structural Patterns Structural Patterns describe classes and objects composition. The difference between class patterns and object patterns is that class patterns describe how inheritance can be used to compose interfaces. Object patterns, on the other hand,s describe how objects can be used to obtain new functionality. [5, 6] • Adapter An adapter design pattern converts the in interface of a class into another interface that clients expect. It allows classes work together that normally could not because of incompatible interfaces by wraping an existing class with a new interface. [2, 5] The adapter pattern can be implemented by both inheritance and by composition. [6] • Bridge A bridge pattern is used to separate out the interface from its implementation so that both can vary independently. [6] The bridge uses encapsulation, aggregation, and can use inheritance to separate responsibilities into different classes. The bridge pattern is useful when not only the class itself varies often but also what the class does. The class itself can be thought of as the implementation and what the class can do as the abstraction. [2] • Composite A composite pattern allows a group of objects to be composed into tree structures to represent part- whole hierarchies. It allows clients treat individual objects and compositions uniformly. [2, 5, 6] • Decorator A decorator pattern attaches new or additional behavior and functionality to an object dynamically. It provides a flexible alternative to subclassing for extending functionality at runtime by adding a new decorator class that wraps the original class. [2, 5] Since the decorator is an object created at runtime, it can be combined on a per-use basis and avoid the problem of some object-oriented programming languages that classes cannot be created at runtime. [2] The decorator and adapter patterns are similar. An adapter seems to decorate the classes and convert the interface of one or more classes to suit the interface of the client program. The intent of decorator is to add behavior and functionality to some of the objects. [6] • Facade A facade pattern is an object that provides a simplified interface to a large body of code. It is used to hides the complexities of the system and provides an interface to the client from where the client can access the system. [2, 6] A facade pattern can make a software library easier to use and understand and allowing more flexibility in developing the system by reducing dependencies of outside code on the inner code. [2] • Flyweight A flyweight pattern describes how to share objects to avoid creating a large number of object instances to represent the entire system. [6] It allows the share objects’ use at fine granularities without pro- hibitive cost. Each flyweight object consists of the state-dependent part, called extrinsic part, and the state-independent part, called intrinsic part. The intrinsic state is stored in the flyweight object while the extrinsic state is stored or computed by client objects and passed to the flyweight when it’s operation are invoked. [5] 3 • Proxy A proxy pattern provides a surrogate or place holder for another object to control access to it by using an extra level of indirection to support distributed, controled, or intelligent access. The proxy will add a wrapper and delegation to protect the real component from undue complexity. [5] Behavioral Patterns Behavioral patterns are those patterns that are most specifically concerned with interactions between class’s objects. [5] • Chain of Responsibility A chain of responsibility pattern decouples the sender of the request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. The chain of responsibility pattern launch and leave requests with a single processing pipeline that contains many possible handlers. [5] • Command A command pattern encapsulates a request as an object, thereby letting you parameterize clients with defferent requests, queue or log requests, and support undoable operations. [5] With this pattern, objects is used to represent actions.[2] The client invokes a particular module using a command and passes a request. This request gets propagated as a command. The command request maps to particular modules. According to the command, a module is invoked. [6] • Interpreter An interpreter pattern defines a grammatical representation for a language along with an interpreter that uses the representation to interpret sentences in the language.