Design Pattern: The Reusable Object Oriented Software Object is a software engineering book that illustrates the design patterns of software. The author of the book is Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with the introduction by Grady Booch. The book is divided into two parts, with the first two chapters exploring capabilities and pitfalls of object-oriented programming, and the remaining chapters illustrate 23 classic software design patterns. This book covers examples in C and Smalltalk.
This has had an impact on the field of software engineering and is considered an important source for object oriented design theory and practice. More than 500,000 copies have been sold in English and 13 other languages. The authors are often referred to as the Gang of Four ( GoF ).
Video Design Patterns
Histori
The book begins at the bird sessions of feathers (BoF) at OOPSLA '90, "Toward the Architecture Handbook", run by Bruce Anderson, where Erich Gamma and Richard Helm meet and find their common interests. They then joined Ralph Johnson and John Vlissides. The original publishing date of the book is October 21, 1994 with copyright 1995, as it is often quoted in 1995, although published in 1994. This book was first made available to the public at the OOPSLA meeting held in Portland. , Oregon, in October 1994. In 2005 ACM SIGPLAN awarded the Programming Language Achievement Achievement award that year to the authors, in recognition of the impact of their work "on programming practice and programming language design". In March 2012, the book was in the 40th print.
Maps Design Patterns
Introduction, Chapter 1
Chapter 1 is a discussion of object-oriented design techniques, based on the author's experience, which they believe will lead to a good object-oriented software design, including:
- "Program to 'interface' instead of ' implementation' ." (Gang of Four 1995: 18)
- Composition over inheritance: "Favorite 'object composition' over 'inherited class'." (Gang of Four 1995: 20)
The authors claim the following as an interface advantage over implementation:
- clients remain unaware of the particular object type they use, as long as the object is attached to the interface
- the client remains unaware of the class that implements these objects; the client only knows about the abstract class (es) defines the interface
The use of interfaces also leads to dynamic bonding and polymorphism, which is a key feature of object-oriented programming.
The authors refer to inheritance as reusing white boxes , with white boxes referring to visibility, since internal parent classes are often visible to subclasses. Instead, the author refers to the composition of the object (where objects with well-defined interfaces are used dynamically at runtime by objects that obtain references to other objects) as black-box reuse because there is no internal detail of the object arranged need to be visible in code using them.
The authors discussed the tension between inheritance and long encapsulation and stated that in their experience, designers too often use inheritance (Ganges 1995: 20). Hazards are expressed as follows:
- "Because inheritance exposes subclasses to the details of its parent implementations, it is often said that 'inheritance corrupts encapsulation'". (Gang of Four 1995: 19)
They warn that subclass implementations can become so closely tied to the implementation of the parent class that any changes in the parent implementation will force the subclass to change. Furthermore, they claim that the way to avoid this is to inherit only from abstract classes - but then, they show that there is minimal code reuse.
Using inheritance is recommended especially when adding to the functionality of existing components, reusing most of the old code and adding a relatively small amount of new code.
For authors, 'delegate' is an extreme form of object composition that can always be used to replace inheritance. Delegates involve two objects: 'sender' escapes to 'delegate' to let the delegate refer to the sender. Thus the relationship between two parts of the system is set only at runtime, not at compile time. Callback articles have more information about delegates.
The authors also discussed the so-called parameter type , which is also known as generic (Ada, Eiffel, Java, C #, VB.NET, and Delphi) or templates (C). This allows all types to be defined without specifying all other types used - the unspecified type is given as a 'parameter' at the point of use.
The authors acknowledge that delegation and parameterization are very powerful but add a warning:
- "Dynamic, highly parameterized software is harder to understand and create than other static software." (Gang of Four 1995: 21)
The authors further distinguish between 'Aggregates', in which one object 'has' or 'is part of' another object (implying that the aggregate object and its owner have identical endurance) and acquaintance , where one objects are just 'Knowing' other objects. Sometimes acquaintances are called 'associations' or 'using' relationships. The contact object can request each other's operations, but they are not responsible for each other. Contacts are weaker relationships than aggregation and show a lot of loose coupling between objects, which are often desired for maximum maintenance in the design.
The authors use the term 'toolkit' where others may today use the 'class library', as in C # or Java. In their language, toolkits are object-oriented subroutine libraries, while the 'framework' is a set of working classes that make up a reusable design for a particular software class. They state that apps are difficult to design, toolkit is more difficult, and framework is the most difficult to design.
Case study, Chapter 2
Chapter 2 is a step-by-step case study on the "What-You-See-What-You-Get (or 'WYSIWYG' document editor design) called Lexi." (pp33)
This chapter addresses seven issues that need to be addressed in order to properly design Lexi, including any obstacles to be followed. Each problem is analyzed in depth, and the solution is proposed. Each solution is described in full, including pseudo-code and a few versions of the appropriate Object Modeling Technique.
Finally, each solution is directly related to one or more design patterns. This is shown how the solution is a direct implementation of the design pattern.
The seven issues (including their constraints) and their solutions (including referenced patterns), are as follows:
Document Structure
Documents are "settings of basic graphical elements" such as characters, lines, other forms, etc., which "capture the contents of the total document information" (pp35). The document structure contains a collection of these elements, and each element in turn can be a substructure of other elements.
Issues and Limitations
- Text and images should be treated in the same way (i.e., graphs instead of derived text derivatives, and vice versa)
- The implementation should treat complex and simple structures in the same way. Should not have to know the difference between the two.
- The specific derivative of the abstract element must have a special analytical element.
Solutions and Patterns
Recursive composition is the hierarchical structure of elements, which builds "an increasingly complex element of simpler" (pp36). Every node in the structure knows its own children and its parents. If the operation should be performed on the entire structure, each node calls the operation on its child (recursively).
This is an implementation of the combined pattern, which is a collection of nodes. Nodes are abstract base classes, and their derivatives can be either a single (leaf), or a collection of other vertices (which in turn can contain leaves or nodes). When surgery is performed on the parent, the operation recursively lowers the hierarchy.
Format
Different formats of structure. Format is a method of constructing a specific example of the physical structure of a document. This includes breaking text into lines, using hyphens, adjusting margin width, etc.
Issues and Limitations
- Balances between (format) quality, speed and storage space
- Save independent formatting (detached) from the document structure.
Solutions and Patterns
The Composite class will encapsulate the algorithm used to format a composition. The compositor is a subclass of the primitive object of the document structure. The compositor has a corresponding instance of the Composite object. When Compositor runs Write () , it iterates through each element of the associated Composition, and rearranges the structure by entering the Row and Column objects as needed.
The compositor itself is an abstract class, allowing derived classes to use different formatting algorithms (such as double spaces, wider margins, etc.)
Pattern Strategies are used to achieve this goal. Strategy is a method of encapsulating some algorithms to use based on changing contexts. In this case, the formatting should be different depending on whether text, graphics, simple elements, etc., are being formatted.
Decorate User Interface
Ability to change the graphical interface that users use to interact with documents.
Problems and Restrictions
- Make demarcate text pages with borders around the editing area
- A scrollbar that allows users to view different sections of the page
- The user interface object should not know about decoration
- Avoid "class boom" that will be caused by a subclass for "every possible combination of decorative" and element (p44)
Solutions and Patterns
The use of transparent cover allows elements that add compositional behavior to be added to the composition. These elements, such as Border and Scroller, are the special subclass of the single element itself. This allows the composition to be added, effectively adding elements like the state. Since these augmentations are part of the structure, the corresponding Operation () will be called when
This is a Decorator pattern, which adds responsibility to the object without modifying the object itself.
Support Multiple View-Feel Standards
Look-and-feel refers to platform-specific UI standards. These standards "define guidelines for how apps appear and react to users" (pp47).
Issues and Limitations
- The editor must implement standard platforms so that it is portable
- Easily adapt to new and new standards
- Allows run-time display and nuance changes (ie: No hard-coding)
- Have a subset of abstract elements for each element category (ScrollBar, Buttons, etc.)
- Have a set of concrete subclasses for each abstract subclass that can have different display and nuance standards. (ScrollBar has MotifScrollBar and PresentationScrollBar for Visible-and-Present Motives and Presentations)
Solutions and Patterns
Since the creation of different concrete objects can not be done at runtime, the process of creating objects must be abstracted. This is done with an abstract guiFactory, which takes responsibility for creating UI elements. The abstract guiFactory has a concrete implementation, such as MotifFactory, which creates a concrete element of the appropriate type (MotifScrollBar). In this way, the program only needs to ask for ScrollBar and, at run-time, will be given the correct concrete element.
This is an Abstract Factory. Ordinary factories create concrete objects of one type. An abstract factory creates concrete objects of various types, depending on the concrete execution of the factory itself. His ability to focus on not only concrete objects, but the whole family of concrete objects "distinguishes them from other creational patterns, which involve only one type of product object" (pp51).
Supports Multiple Window Systems
Just as the look and feel is different across platforms, so is the method of handling windows. Each platform displays, traps, handles inputs to and outputs from, and the windows layer is different.
Issues and Limitations
- The document editor should run on many "important and very incompatible" existing window systems (p.Ã, 52)
- The Abstract Factory can not be used. Because of different standards, there will not be a general abstract class for each type of widget.
- Do not create new non-standard windowing systems
Solutions and Patterns
It is possible to develop "our own abstract and concrete product classes", since "all window systems generally do the same thing" (page 52). Each windows system provides operations for drawing primitive shapes, iconifying/de-iconifying, resizing, and refreshing the contents of windows.
Abstract base class Window can be downgraded to different types of existing windows, such as apps, icons, dialogs. These classes will contain windows related operations, such as reshaping, refreshing graphically, etc. Each window contains an element, which the Draw () function is called by the Window self-drawing function itself.
To avoid having to create a special Window platform subclass for every possible platform, the interface will be used. The Window class will implement the Window implementation ( WindowImp ). This class will then be downgraded into several platform-specific implementations, each with a platform-specific operation. Therefore, only one set of Window classes is required for each type of Window , and only one set of WindowImp classes is required for each platform (rather than Cartesian products of all types and platforms available). Additionally, adding a new window type requires no modification of the platform implementation, or vice versa.
This is the Bridge pattern. Window and WindowImp are different, but related. Window is associated with windowing in the program, and WindowImp corresponds to windowing on the platform. One of them can change without having to modify the other. The Bridge Pattern allows both "separate class hierarchies to work together even when they evolve independently" (p.Ã, 54).
User Operations
All actions users can take with documents, from entering text, changing formatting, pausing, saving, etc.
Issues and Limitations
- Operations must be accessed via different inputs, such as menu options and keyboard shortcuts for the same command
- Each option has an interface, which must be modifiable
- The operation is applied in several different classes
- To avoid merging, there should be no dependency between implementations and user interface classes.
- Undo and repeat commands should be supported in most document editing operations, with no arbitrary restrictions on the number of cancellation levels
- The function is not feasible, because it can not be undone/re-timed easily, not easily linked to a country, and difficult to expand or reuse.
- The menu should be treated like a hierarchical composite structure. Therefore, menus are menu items that contain menu items that may contain other menu items, etc.
Solutions and Patterns
Each menu item, rather than used with a list of parameters, is even done with the Command object.
Command is an abstract object that only has abstract method Execute () . The derivative object extends the exact Execute () method (ie, PasteCommand.Execute () will take advantage of the clipboard's content buffer). These objects can be used by widgets or buttons as easily as they can be used by menu items.
To support undo and redo, Command is also given Unexecute () and Reversible () . In the derivative class, the first contains the code that will cancel the command, and the last one returns a boolean value that defines if the command can not be fixed. Reversible () allows some commands to be irreversible, like the Save command.
All executed Command is stored in the list by keeping the "present" marker directly after the most recently executed command. Request to cancel will call Command.Unexecute () directly before "attending", then move "show" back one command. Instead, the redo request will call Command.Execute () after "present", and move the "present" forward.
This Command approach is an implementation of the Command pattern. It encapsulates the request in the object, and uses the common interface to access the request. Thus, clients can handle different requests, and commands can be spread across applications.
Spellchecking and Hyphilation
This is the ability of the document editor to analyze textually the contents of the document. Although there are many analyzes that can be done, spell checking and formatting hyphenation are the focus.
Issues and Limitations
- Allow multiple ways to check spelling and identify places for termination
- Allow for expansion for future analysis (e.g., word count, grammar checking)
- Be able to repeat via text content without access to the actual text structure (e.g., array, linked list, string)
- Allow for all document traversal (start to end, end to start, alphabetical order, etc.)
Solutions and Patterns
Removing an index based integer of the base element allows for different iterative interfaces to be implemented. This will require additional methods for object search and traversal. This method is inserted into the abstract interface Iterator . Each element then implements the derivation of Iterator , depending on how it stores the list ( ArrayIterator , LinkListIterator , etc.).
Functions for traversal and retrieval are entered into the abstract Iterator interface. Future Iterators can be derived based on the types of lists they want to iterate, such as Arrays or Linked Lists. Thus, no matter what kind of indexing method any implementation of the element is used, it will have the appropriate Iterator.
This is an implementation of Iterator pattern. This allows the client to traverse through each collection of objects, without the need to access the contents of the collection directly, or worry about the type of list used collection structure.
Now that the traversal has been handled, it is possible to analyze the elements of the structure. It is impossible to construct any kind of analysis into the structure of the element itself; each element needs to be encoded, and most of the code will be the same for the same element.
Instead, the generic CheckMe () method is built into an abstract class of elements. Each Iterator is given references to certain algorithms (such as spell checking, grammar checks, etc.). When the Iterator iterates through the collection, it calls every element CheckMe , passes the specified algorithm. CheckMe then passes a reference to its element back to the algorithm for analysis.
So, to do spell checking, a front-to-end iterator will be given a reference to the SpellCheck object. The Iterator will then access each element, execute the CheckMe () method with the SpellCheck parameter. Each CheckMe will then call Check Spelling , passing the reference to the appropriate element.
In this way, any algorithm can be used with the traversal method, without hard-code coupling with each other. For example, Search can be used as "next find" or "find before" depending on whether "forward" iterator is used, or iterator "backwards".
In addition, the algorithm itself can be responsible for handling different elements. For example, the SpellCheck algorithm will ignore the Graphic element, instead of having to program each element Graphic -finish not to send itself to Check Spelling .
Pattern by Type
Creational
Pattern creations are patterns that create objects for you, rather than asking you to instantiate objects directly. This gives your program more flexibility in deciding which objects need to be made for a particular case.
- The abstract factory pattern group refers to a factory with a common theme.
- The builder pattern creates complex objects separating constructs and representations.
- The factory method pattern creates objects without specifying the correct class to create.
- The prototype pattern creates an object by duplicating an existing object.
- The Singleton pattern limits the creation of objects to classes for just one instance.
Structure
Attention to the class and the composition of this object. They use inheritance to construct interfaces and determine how to construct objects to gain new functionality.
- The adapter allows classes with incompatible interfaces to work together by wrapping their own interface around an existing class.
- The bridge separates the abstraction from its implementation so that both can vary separately.
- Composites arrange objects that are more zero or more similar so that it can be manipulated as an object.
- Decorators dynamically add/override behavior in existing object methods.
- The facade provides a simplified interface for a large set of codes.
- The flyweek reduces the cost of creating and manipulating a large number of similar objects.
- Proxies provide placeholders for other objects to control access, reduce costs, and reduce complexity.
Behavior
Most of these design patterns are specifically related to communication between objects .
- The responsibility chain delegates commands to the processing object chain.
- Commands create objects that encapsulate actions and parameters.
- Interpreter applies a special language.
- Iterators access object elements in sequence without exposing their basic representations.
- Mediators allow for loose coupling between classes by being the only classes with detailed knowledge of their methods.
- Memento provides the ability to return an object to its previous state (undo).
- Observer is a publishing/subscription pattern that allows a number of observer objects to view the event.
- Status allows objects to change their behavior when their internal circumstances change.
- Strategy allows one of the algorithm families to choose when flying at runtime.
- The template method defines the framework of an algorithm as an abstract class, allowing its subclass to provide concrete behavior.
- The visitor separates the algorithm from the object structure by moving the method hierarchy into one object.
Criticism
Significant criticism has been directed to the concept of general software design patterns, and on the Design Pattern specifically.
The main criticism of Design Pattern is that the patterns are only a solution to the missing feature in C, replacing the elegant abstract feature with a long concrete pattern, which is basically a "human compiler" or "generating with hand expansion of some macros ". Peter Norvig points out that 16 of 23 patterns in Design Pattern are simplified or eliminated (via direct language support) in Lisp or Dylan. Related observations were made by Hannemann and Kiczales applying some of the 23 design patterns using aspect-oriented programming language (AspectJ) and showing that code-level dependencies have been removed from implementation 17 of 23 design patterns and program oriented aspects can simplify the application of design patterns.
Paul Graham menulis:
When I see the pattern in my program, I take it as a sign of trouble. The form of the program should reflect only the problems that need to be solved. Other regularities in the code are a sign, at least for me, that I use abstractions that are not strong enough - often I generate by hand the expansion of some macros that I need to write.
There were also funny criticisms, such as the show trials at OOPSLA '99 on November 3, 1999, and a parody format, by Jim Coplien, entitled "Kansas City Air Conditioner".
See also
- Software design patterns
- Company Integration Pattern
- GRASP (object-oriented design)
- Pedagogical pattern
Note
References
Source of the article : Wikipedia
0 Comments