DOCSLIB.ORG

Design Patterns: Abstraction and Reuse of Object-Oriented Design

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Patterns: Abstraction and Reuse of Object-Oriented Design Design Patterns: Abstraction and Reuse of Ob ject-Oriented Design 1? 2 3 2 Erich Gamma , Richard Helm , Ralph Johnson , John Vlissides 1 Taligent, Inc. 10725 N. De Anza Blvd., Cup ertino, CA 95014-2000 USA 2 I.B.M. Thomas J. Watson Research Center P.O. Box 704, Yorktown Heights, NY 10598 USA 3 Department of Computer Science University of Illinoi s at Urbana-Champaign 1034 W. Spring eld Ave., Urbana, IL 61801 USA Abstract. We prop ose design patterns as a new mechanism for expressing ob ject-oriented design exp erience. Design patterns identify, name, and abstract common themes in ob ject- oriented design. They capture the intent b ehind a design by identifying ob jects, their col- lab orations, and the distributio n of resp onsibil i ties. Design patterns play many roles in the ob ject-oriented development pro cess: they provide a common vo cabulary for design, they re- duce system complexityby naming and de ning abstractions, they constitute a base of ex- p erience for buildin g reusable software, and they act as building blo cks from which more complex designs can b e built. Design patterns can b e considered reusable micro-architectures that contribute to an overall system architecture. We describ e how to express and organize design patterns and intro duce a catalog of design patterns. We also describ e our exp erience in applying design patterns to the design of ob ject-oriented systems. 1 Intro duction Design metho ds are supp osed to promote go o d design, to teach new designers how to design well, and to standardize the way designs are develop ed. Typically, a design metho d comprises a set of syntactic notations usually graphical and a set of rules that govern how and when to use each notation. It will also describ e problems that o ccur in a design, how to x them, and howtoevaluate a design. Studies of exp ert programmers for conventional languages, however, have shown that knowledge is not organized simply around syntax, but in larger conceptual structures such as algorithms, data structures and idioms [1, 7, 9, 27], and plans that indicate steps necessary to ful ll a particular goal [26]. It is likely that designers do not think ab out the notation they are using for recording the design. Rather, they lo ok for patterns to match against plans, algorithms, data structures, and idioms they have learned in the past. Go o d designers, it app ears, rely on large amounts of design exp erience, and this exp erience is just as imp ortant as the notations for recording designs and the rules for using those notations. Our exp erience with the design of ob ject-oriented systems and frameworks [15,17,22, 30, 31] b ears out this observation. Wehave found that there exist idiomatic class and ob ject structures that help make designs more exible, reusable, and elegant. For example, the Mo del-View-Controller MVC paradigm from Smalltalk [19] is a design structure that separates representation from pre- sentation. MVC promotes exibility in the choice of views, indep endent of the mo del. Abstract factories [10] hide concrete sub classes from the applications that use them so that class names are not hard-wired into an application. ? Work p erformed while at UBILAB, Union Bank of Switzerland, Zurich, Switzerland. To app ear in ECOOP '93 ConferenceProceedings, Springer-VerlagLecture Notes in Computer Science. Well-de ned design structures like these have a p ositive impact on software development. A software architect who is familiar with a go o d set of design structures can apply them immediately to design problems without having to rediscover them. Design structures also facilitate the reuse of successful architectures|expressing proven techniques as design structures makes them more readily accessible to develop ers of new systems. Design structures can even improve the do cumentation and maintenance of existing systems by furnishing an explicit sp eci cation of class and ob ject interactions and their underlying intent. To this end we prop ose design patterns, a new mechanism for expressing design structures. Design patterns identify, name, and abstract common themes in ob ject-oriented design. They pre- serve design information by capturing the intent b ehind a design. They identify classes, instances, their roles, collab orations, and the distribution of resp onsibilities. Design patterns have many uses in the ob ject-oriented development pro cess: { Design patterns provide a common vo cabulary for designers to communicate, do cument, and explore design alternatives. They reduce system complexityby naming and de ning abstractions that are ab ove classes and instances. A go o d set of design patterns e ectively raises the level at which one programs. { Design patterns constitute a reusable base of exp erience for building reusable software. They distill and provide a means to reuse the design knowledge gained by exp erienced practitioners. Design patterns act as building blo cks for constructing more complex designs; they can b e considered micro-architectures that contribute to overall system architecture. { Design patterns help reduce the learning time for a class library. Once a library consumer has learned the design patterns in one library, he can reuse this exp erience when learning a new class library. Design patterns help a novice p erform more like an exp ert. { Design patterns provide a target for the reorganization or refactoring of class hierarchies [23]. Moreover, by using design patterns early in the lifecycle, one can avert refactoring at later stages of design. The ma jor contributions of this pap er are: a de nition of design patterns, a means to describ e them, a system for their classi cation, and most imp ortantly, a catalog containing patterns wehave discovered while building our own class libraries and patterns wehave collected from the literature. This work has its ro ots in Gamma's thesis [11], which abstracted design patterns from the ET++ framework. Since then the work has b een re ned and extended based on our collective exp erience. Our thinking has also b een in uenced and inspired by discussions within the Architecture Handb o ok Workshops at recent OOPSLA conferences [3, 4]. This pap er has two parts. The rst intro duces design patterns and explains techniques to describ e them. Next we present a classi cation system that characterizes common asp ects of patterns. This classi cation will serve to structure the catalog of patterns presented in the second part of this pap er. We discuss how design patterns impact ob ject-oriented programming and design. We also review related work. The second part of this pap er the App endix describ es our current catalog of design patterns. As we cannot include the complete catalog in this pap er it currently runs over 90 pages [12], we give instead a brief summary and include a few abridged patterns. Each pattern in this catalog is representative of what we judge to b e go o d ob ject-oriented design. Wehave tried to reduce the sub jectivity of this judgmentby including only design patterns that have seen practical application. Every design pattern wehave included works|most have b een used at least twice and have either b een discovered indep endently or have b een used in a variety of application domains. 2 Design Patterns A design pattern consists of three essential parts: 1. An abstract description of a class or ob ject collab oration and its structure. The description is abstract b ecause it concerns abstract design, not a particular design. 2. The issue in system design addressed by the abstract structure. This determines the circum- stances in which the design pattern is applicable. 3. The consequences of applying the abstract structure to a system's architecture. These determine if the pattern should b e applied in view of other design constraints. Design patterns are de ned in terms of ob ject-oriented concepts. They are suciently abstract to avoid sp ecifying implementation details, thereby ensuring wide applicability, but a pattern may provide hints ab out p otential implementation issues. We can think of a design pattern as a micro-architecture. It is an architecture in that it serves as a blueprint that mayhave several realizations. It is \micro" in that it de nes something less than a complete application or library.To b e useful, a design pattern should b e applicable to more than a few problem domains; thus design patterns tend to b e relatively small in size and scop e. A design pattern can also b e considered a transformation of system structure. It de nes the context for the transformation, the change to b e made, and the consequences of this transformation. To help readers understand patterns, eachentry in the catalog also includes detailed descriptions and examples. We use a template Figure 1 to structure our descriptions and to ensure uniformity between entries in the catalog. This template also explains the motivation b ehind its structure. The App endix contains three design patterns that use the template. We urge readers to study the patterns in the App endix as they are referenced in the following text. 3 Categorizing Design Patterns Design patterns vary in their granularity and level of abstraction. They are numerous and have common prop erties. Because there are many design patterns, we need a way to organize them. This section intro duces a classi cation system for design patterns. This classi cation makes it easy to refer to families of related patterns, to learn the patterns in the catalog, and to nd new patterns.
Load more

Recommended publications
  • Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp
    Kyle Brown An Introduction to Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp. 4001 Weston Parkway CSC591O Cary, North Carolina 27513-2303 April 7-9, 1997 919-481-4000 Raleigh, NC [email protected] http://www.ksccary.com Copyright (C) 1996, Kyle Brown, Bobby Woolf, and 1 2 Knowledge Systems Corp. All rights reserved. Overview Bobby Woolf Senior Member of Technical Staff O Patterns Knowledge Systems Corp. O Software Patterns 4001 Weston Parkway O Design Patterns Cary, North Carolina 27513-2303 O Architectural Patterns 919-481-4000 O Pattern Catalogs [email protected] O Pattern Languages http://www.ksccary.com 3 4 Patterns -- Why? Patterns -- Why? !@#$ O Learning software development is hard » Lots of new concepts O Must be some way to » Hard to distinguish good communicate better ideas from bad ones » Allow us to concentrate O Languages and on the problem frameworks are very O Patterns can provide the complex answer » Too much to explain » Much of their structure is incidental to our problem 5 6 Patterns -- What? Patterns -- Parts O Patterns are made up of four main parts O What is a pattern? » Title -- the name of the pattern » A solution to a problem in a context » Problem -- a statement of what the pattern solves » A structured way of representing design » Context -- a discussion of the constraints and information in prose and diagrams forces on the problem »A way of communicating design information from an expert to a novice » Solution -- a description of how to solve the problem » Generative:
    [Show full text]
  • Wiki As Pattern Language
    Wiki as Pattern Language Ward Cunningham Cunningham and Cunningham, Inc.1 Sustasis Foundation Portland, Oregon Michael W. Mehaffy Faculty of Architecture Delft University of Technology2 Sustasis Foundation Portland, Oregon Abstract We describe the origin of wiki technology, which has become widely influential, and its relationship to the development of pattern languages in software. We show here how the relationship is deeper than previously understood, opening up the possibility of expanded capability for wikis, including a new generation of “federated” wiki. [NOTE TO REVIEWERS: This paper is part first-person history and part theory. The history is given by one of the participants, an original developer of wiki and co-developer of pattern language. The theory points toward future potential of pattern language within a federated, peer-to-peer framework.] 1. Introduction Wiki is today widely established as a kind of website that allows users to quickly and easily share, modify and improve information collaboratively (Leuf and Cunningham, 2001). It is described on Wikipedia – perhaps its best known example – as “a website which allows its users to add, modify, or delete its content via a web browser usually using a simplified markup language or a rich-text editor” (Wikipedia, 2013). Wiki is so well established, in fact, that a Google search engine result for the term displays approximately 1.25 billion page “hits”, or pages on the World Wide Web that include this term somewhere within their text (Google, 2013a). Along with this growth, the definition of what constitutes a “wiki” has broadened since its introduction in 1995. Consider the example of WikiLeaks, where editable content would defeat the purpose of the site.
    [Show full text]
  • One-Slide Summary Lecture Outline
    Using Design Patterns #1 One-Slide Summary • Design patterns are solutions to recurring OOP design problems. There are patterns for constructing objects, structuring data, and object behavior . • Since this is PL, we’ll examine how language features like (multiple) inheritance and dynamic dispatch relate to design patterns. #2 Lecture Outline • Design Patterns • Iterator • Observer • Singleton • Mediator #3 1 What is a design pattern? • A solution for a recurring problem in a large object-oriented programming system – Based on Erich Gamma’s Ph.D. thesis, as presented in the “gang of four” book • “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” – Charles Alexander #4 Types of design patterns • Design patterns can be (roughly) grouped into three categories: • Creational patterns – Constructing objects • Structural patterns – Controlling the structure of a class, e.g. affecting the API or the data structure layout • Behavioral patterns – Deal with how the object behaves #5 Iterator design pattern • Often you may have to move through a collection – Tree (splay, AVL, binary, red-black, etc.), linked list, array, hash table, dictionary, etc. • Easy for arrays and vectors • But hard for more complicated data structures – Hash table, dictionary, etc. • The code doing the iteration should not have to know the details of the data structure
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • From a Pattern Language to a Field of Centers and Beyond Patterns and Centers, Innovation, Improvisation, and Creativity
    From a Pattern Language to a Field of Centers and Beyond Patterns and Centers, Innovation, Improvisation, and Creativity Hajo Neis Illustration 1: University of Oregon in Portland Downtown Urban Campus The Campus is located in downtown Portland in adapted old warehouse buildings, and was first designed in the Oregon pattern language method with the principles of pat- terns and user participation. The White Stag building facilities are open since 2009. 144 Hajo Neis INTRODUCTION What we call now the ›overall pattern language approach‹ in architecture, urban design, and planning has grown from its original principle of ›pattern and pat- tern language‹ into a large and solid body of theory and professional work. To- day, pattern theory and practice includes a large number of principles, methods, techniques and practical project applications in which patterns themselves play a specific part within this larger body of knowledge. Not only has the pattern lan- guage approach grown in its original area of architecture, but it has also (though less triumphantly than silently) expanded into a large number of other disciplines and fields, in particular computer and software science, education, biology, com- munity psychology, and numerous practical fields. Nevertheless, we first have to acknowledge that the pattern approach originally started with a single principle almost 50 years ago, the principle of pattern and pattern language that gave the name to this school of thought and practical professional project work. In this article we want to trace some of the theoretical and practical develop- ment of the pattern method and its realization in practical projects. We want to explore how challenges and opportunities resulted in the adaptation of the pattern language method into various forms of pattern project formats and formulations including ›pattern language‹ and ›project language.‹ We want to look at various forms of innovations and techniques that deal with theoretical improvements as well as the necessities of adaptation for practical cases and projects.
    [Show full text]
  • Object-Oriented Analysis, Design and Implementation
    Undergraduate Topics in Computer Science Brahma Dathan Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition Undergraduate Topics in Computer Science Undergraduate Topics in Computer Science (UTiCS) delivers high-quality instruc- tional content for undergraduates studying in all areas of computing and information science. From core foundational and theoretical material to final-year topics and applications, UTiCS books take a fresh, concise, and modern approach and are ideal for self-study or for a one- or two-semester course. The texts are all authored by established experts in their fields, reviewed by an international advisory board, and contain numerous examples and problems. Many include fully worked solutions. More information about this series at http://www.springer.com/series/7592 Brahma Dathan • Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition 123 Brahma Dathan Sarnath Ramnath Department of Information and Computer Department of Computer Science Science and Information Technology Metropolitan State University St. Cloud State University St. Paul, MN St. Cloud, MN USA USA Series editor Ian Mackie Advisory Board Samson Abramsky, University of Oxford, Oxford, UK Karin Breitman, Pontifical Catholic University of Rio de Janeiro, Rio de Janeiro, Brazil Chris Hankin, Imperial College London, London, UK Dexter Kozen, Cornell University, Ithaca, USA Andrew Pitts, University of Cambridge, Cambridge, UK Hanne Riis Nielson, Technical University of Denmark, Kongens Lyngby, Denmark Steven Skiena, Stony Brook University, Stony Brook, USA Iain Stewart, University of Durham, Durham, UK A co-publication with the Universities Press (India) Private Ltd., licensed for sale in all countries outside of India, Pakistan, Bhutan, Bangladesh, Sri Lanka, Nepal, The Maldives, Middle East, Malaysia, Indonesia and Singapore.
    [Show full text]
  • Principles of Design
    Principles of Design Balance Proportion/Scale Emphasis Rhythm Introduction The principles of design are essential to the development and production of clothing used by individuals and families around the world. Each principle has a specific role in creating an aesthetically pleasing garment or ensemble. The principles of design consist of: balance, proportion (also referred to as scale), emphasis, and rhythm. When a garment or ensemble uses the elements and principles of design to create a visual unity, harmony is achieved. Garments often integrate more than one principle, while drawing from the elements of design to create a cohesive look. The following discussion will present background information on each of the principles of design and applications to clothing design and construction. Balance According to Wolfe (2011) balance implies that there is an equilibrium or uniformity among the parts of a design (p. 205). To achieve balance, a garment or ensemble should have equal visual weight throughout the design. The use of structural features, added embellishments, or decorations to a garment contribute to the appearance of a garment or ensemble being balanced or not. A clothing designer can utilize surface designs on fabric to construct a garment creating visual balance. Further, color, line, and texture can impact the balance of a design. For example, cool and light colors have less visual weight than dark, warm colors. If an individual is wearing a small amount of a dark, warm color it can be balanced out with a larger amount of cool, light colors. Balance used in clothing design can be categorized into two groups: Formal and Informal Balance.
    [Show full text]
  • APPLYING MODEL-VIEW-CONTROLLER (MVC) in DESIGN and DEVELOPMENT of INFORMATION SYSTEMS an Example of Smart Assistive Script Breakdown in an E-Business Application
    APPLYING MODEL-VIEW-CONTROLLER (MVC) IN DESIGN AND DEVELOPMENT OF INFORMATION SYSTEMS An Example of Smart Assistive Script Breakdown in an e-Business Application Andreas Holzinger, Karl Heinz Struggl Institute of Information Systems and Computer Media (IICM), TU Graz, Graz, Austria Matjaž Debevc Faculty of Electrical Engineering and Computer Science, University of Maribor, Maribor, Slovenia Keywords: Information Systems, Software Design Patterns, Model-view-controller (MVC), Script Breakdown, Film Production. Abstract: Information systems are supporting professionals in all areas of e-Business. In this paper we concentrate on our experiences in the design and development of information systems for the use in film production processes. Professionals working in this area are neither computer experts, nor interested in spending much time for information systems. Consequently, to provide a useful, useable and enjoyable application the system must be extremely suited to the requirements and demands of those professionals. One of the most important tasks at the beginning of a film production is to break down the movie script into its elements and aspects, and create a solid estimate of production costs based on the resulting breakdown data. Several film production software applications provide interfaces to support this task. However, most attempts suffer from numerous usability deficiencies. As a result, many film producers still use script printouts and textmarkers to highlight script elements, and transfer the data manually into their film management software. This paper presents a novel approach for unobtrusive and efficient script breakdown using a new way of breaking down text into its relevant elements. We demonstrate how the implementation of this interface benefits from employing the Model-View-Controller (MVC) as underlying software design paradigm in terms of both software development confidence and user satisfaction.
    [Show full text]
  • A Pattern Approach to Interaction Design
    A Pattern Approach to Interaction Design Jan O. Borchers Department of Computer Science Darmstadt University of Technology Alexanderstr. 6, 64283 Darmstadt, Germany [email protected] ABSTRACT perts need to work together very closely with team members To create successful interactive systems, user interface de- from other disciplines. Most notably, they need to coop- signers need to cooperate with developers and application erate with application domain experts to identify the con- domain experts in an interdisciplinary team. These groups, cepts, tasks, and terminology of the product environment, however, usually miss a common terminology to exchange and with the development team to make sure the internal ideas, opinions, and values. system design supports the interaction techniques required. This paper presents an approach that uses pattern languages However, these disciplines lack a common language: It is to capture this knowledge in software development, HCI, difficult for the user interface designer to explain his guide- and the application domain. A formal, domain-independent lines and concerns to the other groups. It is often even definition of design patterns allows for computer support more problematic to extract application domain concepts without sacrificing readability, and pattern use is integrated from the user representative in a usable form. And it is into the usability engineering life cycle. hard for HCI people, and for application domain experts even more so, to understand the architectural and techno- As an example, experience from building an award-winning logical constraints and rules that guide the systems engineer interactive music exhibit was turned into a pattern language, in her design process.
    [Show full text]
  • A Design Pattern Detection Tool for Code Reuse
    DP-CORE: A Design Pattern Detection Tool for Code Reuse Themistoklis Diamantopoulos, Antonis Noutsos and Andreas Symeonidis Electrical and Computer Engineering Dept., Aristotle University of Thessaloniki, Thessaloniki, Greece [email protected], [email protected], [email protected] Keywords: Design Pattern Detection, Static Code Analysis, Reverse Engineering, Code Reuse. Abstract: In order to maintain, extend or reuse software projects one has to primarily understand what a system does and how well it does it. And, while in some cases information on system functionality exists, information covering the non-functional aspects is usually unavailable. Thus, one has to infer such knowledge by extracting design patterns directly from the source code. Several tools have been developed to identify design patterns, however most of them are limited to compilable and in most cases executable code, they rely on complex representations, and do not offer the developer any control over the detected patterns. In this paper we present DP-CORE, a design pattern detection tool that defines a highly descriptive representation to detect known and define custom patterns. DP-CORE is flexible, identifying exact and approximate pattern versions even in non-compilable code. Our analysis indicates that DP-CORE provides an efficient alternative to existing design pattern detection tools. 1 INTRODUCTION ecutable. As a result, developers cannot exploit the source code of other systems without first resolving Developers need to understand existing projects in or- their dependencies and executing them correctly. Sec- der to maintain, extend, or reuse them. However, un- ondly, pattern representations in most tools are not in- derstanding usually comes down to understanding the tuitive, thus resulting in black box systems that do not source code of a project, which is inherently difficult, allow the developer any control over the detected pat- especially when the original software architecture and terns.
    [Show full text]
  • Pattern Languages in HCI: a Critical Review
    HUMAN–COMPUTER INTERACTION, 2006, Volume 21, pp. 49–102 Copyright © 2006, Lawrence Erlbaum Associates, Inc. Pattern Languages in HCI: A Critical Review Andy Dearden Sheffield Hallam University Janet Finlay Leeds Metropolitan University ABSTRACT This article presents a critical review of patterns and pattern languages in hu- man–computer interaction (HCI). In recent years, patterns and pattern languages have received considerable attention in HCI for their potential as a means for de- veloping and communicating information and knowledge to support good de- sign. This review examines the background to patterns and pattern languages in HCI, and seeks to locate pattern languages in relation to other approaches to in- teraction design. The review explores four key issues: What is a pattern? What is a pattern language? How are patterns and pattern languages used? and How are values reflected in the pattern-based approach to design? Following on from the review, a future research agenda is proposed for patterns and pattern languages in HCI. Andy Dearden is an interaction designer with an interest in knowledge sharing and communication in software development. He is a senior lecturer in the Com- munication and Computing Research Centre at Sheffield Hallam University. Janet Finlay is a usability researcher with an interest in design communication and systems evaluation. She is Professor of Interactive Systems in Innovation North at Leeds Metropolitan University. 50 DEARDEN AND FINLAY CONTENTS 1. INTRODUCTION 2. THE SCOPE OF THIS REVIEW 2.1. General Software Design Patterns 2.2. Interface Software Design Patterns 2.3. Interaction Design Patterns 3. A SHORT HISTORY OF PATTERNS 3.1.
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]