Design patterns gof book pdf

Leave this field empty. Exact matches only. Search in title. Search in content. Search in excerpt. The singleton pattern restricts the initialization of a class to ensure that only one instance of the class can be created. The factory pattern takes out the responsibility of instantiating a object from the class to a Factory class. Abstract Factory. Creating a new object instance from another similar instance and then modify according to our requirements.

Provides an interface between two unrelated entities so that they can work together. Used when we have to implement a part-whole hierarchy. For example, a diagram made of other pieces such as circle, square, triangle, etc. Caching and reusing object instances, used with immutable objects. For example, string pool. Creating a wrapper interfaces on top of existing interfaces to help client applications.

The bridge design pattern is used to decouple the interfaces from implementation and hiding the implementation details from the client program. The danger is stated as follows:. They warn that the implementation of a subclass can become so bound up with the implementation of its parent class that any change in the parent's implementation will force the subclass to change.

Furthermore, they claim that a way to avoid this is to inherit only from abstract classes—but then, they point out that there is minimal code reuse.

Using inheritance is recommended mainly when adding to the functionality of existing components, reusing most of the old code and adding relatively small amounts of new code. To the authors, 'delegation' is an extreme form of object composition that can always be used to replace inheritance. Delegation involves two objects: a 'sender' passes itself to a 'delegate' to let the delegate refer to the sender.

Thus the link between two parts of a system are established only at runtime, not at compile-time. The Callback article has more information about delegation. These allow any type to be defined without specifying all the other types it uses—the unspecified types are supplied as 'parameters' at the point of use.

The authors further distinguish between 'Aggregation', where one object 'has' or 'is part of' another object implying that an aggregate object and its owner have identical lifetimes and acquaintance , where one object merely 'knows of' another object. Sometimes acquaintance is called 'association' or the 'using' relationship. Acquaintance objects may request operations of each other, but they aren't responsible for each other.

Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects, which can often be desirable for maximum maintainability in a design. The authors employ the term 'toolkit' where others might today use 'class library', as in C or Java.

In their parlance, toolkits are the object-oriented equivalent of subroutine libraries, whereas a 'framework' is a set of cooperating classes that make up a reusable design for a specific class of software. They state that applications are hard to design, toolkits are harder, and frameworks are the hardest to design.

The chapter goes through seven problems that must be addressed in order to properly design Lexi, including any constraints that must be followed. Each problem is analyzed in depth, and solutions are proposed. Each solution is explained in full, including pseudo-code and a slightly modified version of Object Modeling Technique where appropriate. Finally, each solution is associated directly with one or more design patterns.

It is shown how the solution is a direct implementation of that design pattern. The seven problems including their constraints and their solutions including the pattern s referenced , are as follows:. The document is 'an arrangement of basic graphical elements' such as characters, lines, other shapes, etc. The structure of the document contains a collection of these elements, and each element can in turn be a substructure of other elements. A recursive composition is a hierarchical structure of elements, that builds 'increasingly complex elements out of simpler ones' pp.

Each node in the structure knows of its own children and its parent. If an operation is to be performed on the whole structure, each node calls the operation on its children recursively.

This is an implementation of the composite pattern, which is a collection of nodes. The node is an abstract base class, and derivatives can either be leaves singular , or collections of other nodes which in turn can contain leaves or collection-nodes. When an operation is performed on the parent, that operation is recursively passed down the hierarchy.

Formatting differs from structure. Formatting is a method of constructing a particular instance of the document's physical structure. This includes breaking text into lines, using hyphens, adjusting for margin widths, etc. A Compositor class will encapsulate the algorithm used to format a composition.

Compositor is a subclass of the primitive object of the document's structure. A Compositor has an associated instance of a Composition object.

When a Compositor runs its Compose , it iterates through each element of its associated Composition, and rearranges the structure by inserting Row and Column objects as needed.

The Compositor itself is an abstract class, allowing for derivative classes to use different formatting algorithms such as double-spacing, wider margins, etc. The Strategy Pattern is used to accomplish this goal. A Strategy is a method of encapsulating multiple algorithms to be used based on a changing context. In this case, formatting should be different, depending on whether text, graphics, simple elements, etc. The use of a transparent enclosure allows elements that augment the behaviour of composition to be added to a composition.

These elements, such as Border and Scroller, are special subclasses of the singular element itself. This allows the composition to be augmented, effectively adding state-like elements. Since these augmentations are part of the structure, their appropriate Operation will be called when the structure's Operation is called. This means that the client does not need any special knowledge or interface with the structure in order to use the embellishments.

This is a Decorator pattern, one that adds responsibilities to an object without modifying the object itself. Look-and-feel refers to platform-specific UI standards. These standards 'define guidelines for how applications appear and react to the user' pp. Since object creation of different concrete objects cannot be done at runtime, the object creation process must be abstracted.

This is done with an abstract guiFactory, which takes on the responsibility of creating UI elements. The abstract guiFactory has concrete implementations, such as MotifFactory, which creates concrete elements of the appropriate type MotifScrollBar.

In this way, the program need only ask for a ScrollBar and, at run-time, it will be given the correct concrete element. This is an Abstract Factory. A regular factory creates concrete objects of one type. An abstract factory creates concrete objects of varying types, depending on the concrete implementation of the factory itself. Its ability to focus on not just concrete objects, but entire families of concrete objects 'distinguishes it from other creational patterns, which involve only one kind of product object' pp.

Just as look-and-feel is different across platforms, so is the method of handling windows. Each platform displays, lays out, handles input to and output from, and layers windows differently. It is possible to develop 'our own abstract and concrete product classes', because 'all window systems do generally the same thing' p.

An abstract base Window class can be derived to the different types of existing windows, such as application, iconified, dialog. These classes will contain operations that are associated with windows, such as reshaping, graphically refreshing, etc. Each window contains elements, whose Draw functions are called upon by the Window 's own draw-related functions. In order to avoid having to create platform-specific Window subclasses for every possible platform, an interface will be used.

The Window class will implement a Window implementation WindowImp abstract class. This class will then in turn be derived into multiple platform-specific implementations, each with platform-specific operations. Hence, only one set of Window classes are needed for each type of Window , and only one set of WindowImp classes are needed for each platform rather than the Cartesian product of all available types and platforms. In addition, adding a new window type does not require any modification of platform implementation, or vice versa.

This is a Bridge pattern. Window and WindowImp are different, but related. Window deals with windowing in the program, and WindowImp deals with windowing on a platform.

One of them can change without ever having to modify the other. The Bridge pattern allows these two 'separate class hierarchies to work together even as they evolve independently' p. All actions the user can take with the document, ranging from entering text, changing formatting, quitting, saving, etc.

Each menu item, rather than being instantiated with a list of parameters, is instead done with a Command object.

Command is an abstract object that only has a single abstract Execute method. Derivative objects extend the Execute method appropriately i. Execute would utilize the content's clipboard buffer. These objects can be used by widgets or buttons just as easily as they can be used by menu items. To support undo and redo, Command is also given Unexecute and Reversible.

In derivative classes, the former contains code that will undo that command, and the latter returns a boolean value that defines if the command is undoable. Reversible allows some commands to be non-undoable, such as a Save command.

All executed Commands are kept in a list with a method of keeping a 'present' marker directly after the most recently executed command. A request to undo will call the Command. Unexecute directly before 'present', then move 'present' back one command. Conversely, a Redo request will call Command.

Execute after 'present', and move 'present' forward one. This Command approach is an implementation of the Command pattern. It encapsulates requests in objects, and uses a common interface to access those requests. Thus, the client can handle different requests, and commands can be scattered throughout the application.

This is the document editor's ability to textually analyze the contents of a document. Although there are many analyses that can be performed, spell check and hyphenation-formatting are the focus. Removing the integer-based index from the basic element allows for a different iteration interface to be implemented.

This will require extra methods for traversal and object retrieval. These methods are put into an abstract Iterator interface. Each element then implements a derivation of the Iterator , depending on how that element keeps its list ArrayIterator , LinkListIterator , etc. Functions for traversal and retrieval are put into the abstract Iterator interface.

Future Iterators can be derived based on the type of list they will be iterating through, such as Arrays or Linked Lists. Thus, no matter what type of indexing method any implementation of the element uses, it will have the appropriate Iterator.

This is an implementation of the Iterator pattern. It allows the client to traverse through any object collection, without needing to access the contents of the collection directly, or be concerned about the type of list the collection's structure uses.