DOCSLIB.ORG

Modularizing Design Patterns with Aspects: a Quantitative Study Alessandro Garcia Cláudio Sant’Anna Eduardo Figueiredo

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Modularizing Design Patterns with Aspects: a Quantitative Study Alessandro Garcia Cláudio Sant’Anna Eduardo Figueiredo Modularizing Design Patterns with Aspects: A Quantitative Study Alessandro Garcia Cláudio Sant’Anna Eduardo Figueiredo Uirá Kulesza Carlos Lucena Arndt von Staa Software Engineering Laboratory - Computer Science Department Pontifical Catholic University of Rio de Janeiro – PUC-Rio {afgarcia; claudio; emagno; uira; lucena, arndt}@les.inf.puc-rio.br ABSTRACT aspect-oriented approaches [13, 19] support improved Design patterns offer flexible solutions to common problems in modularization of the crosscutting concerns relative to the software development. Recent studies have shown that several patterns. design patterns involve crosscutting concerns. Unfortunately, To the best of our knowledge, Hannemann and Kiczales [9] have object-oriented (OO) abstractions are often not able to modularize developed the only systematic study that explicitly investigated those crosscutting concerns, which in turn decrease the system the use of aspects to implement classical design patterns. They reusability and maintainability. Hence, it is important verifying performed a preliminary study in which they developed and whether aspect-oriented approaches support improved compared Java [11] and AspectJ [2] implementations of the GoF modularization of crosscutting concerns relative to design patterns. Their findings have shown that AspectJ implementations patterns. Ideally, quantitative studies should be performed to improve the modularity of most patterns. However, these compare OO and aspect-oriented implementations of classical improvements were based on some attributes that are not well patterns with respect to important software engineering attributes, known in software engineering, such as composability and such as coupling and cohesion. This paper presents a quantitative (un)pluggability. Moreover, this study was based only on a study that compares aspect-based and OO solutions for the 23 qualitative assessment and empirical data is missing. To solve this Gang-of-Four patterns. We have used stringent software problem, this previous study should be replicated and engineering attributes as the assessment criteria. We have found supplemented by quantitative case studies in order to improve our that most aspect-oriented solutions improve separation of pattern- knowledge body about the use of aspects for addressing the related concerns, although only 4 aspect-oriented implementations crosscutting property of design patterns. have exhibited significant reuse. This paper complements Hannemann and Kiczales’ work [9] by performing quantitative assessments of Java and AspectJ Keywords implementations for the 23 GoF patterns. Our study was based on Design patterns, aspect-oriented programming, metrics. well-known software engineering attributes such as separation of concerns, coupling, cohesion, and size. We have found that most 1. INTRODUCTION aspect-oriented solutions improved the separation of pattern- Since the introduction of the first software pattern catalog related concerns. In addition, we have found that: containing the 23 Gang-of-Four (GoF) patterns [5], design (i) the use of aspects helped to improve the coupling and patterns have quickly been recognized to be important and useful cohesion of some pattern implementations; in real software development. A design pattern describes a proven (ii) the “aspectization” of design patterns reduced the number of solution to a design problem with the goal of assuring reusable attributes of 10 patterns, and decreased the number of and maintainable solutions. Patterns assign roles to their operations and respective parameters of 12 patterns; participants, which define the functionality of the participants in (iii) only 4 design patterns implemented in AspectJ have the pattern context. However, a number of design patterns involve exhibited significant reuse; crosscutting concerns in the relationship between the pattern roles (iv) the relationships between pattern roles and application- and participant classes in each instance of the pattern [9]. The specific concerns are sometimes so intense that it seems not pattern roles often crosscut several classes in a software system. trivial to separate those roles in aspects; and Moreover, recent studies [7, 8, 9] have shown that object-oriented (v) the use of coupling, cohesion and size measures was helpful abstractions are not able to modularize these pattern-specific to assist the detection of opportunities for aspect-oriented concerns and tend to lead to programs with poor modularity. In refactoring of design patterns. this context, it is important to systematically verify whether The remainder of this paper is organized as follows. Section 2 presents our study setting, while giving a brief description of Hannemann and Kiczales’ study. Section 3 presents the study AOSD 05 Chicago Illinois USA results with respect to separation of concerns, and Section 4 © 2005 ACM 1-59593-042-6/05/03....$5.00 Permission to make digital or hard copies of all or part of this work for presents the study results in terms of coupling, cohesion and size personal or classroom use is granted without fee provided that copies are attributes. These results are interpreted and discussed in Section 5. not made or distributed for profit or commercial advantage and that Section 6 introduces some related work. Section 7 includes some copies bear this notice and the full citation on the first page. To copy concluding remarks. otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee 3 2. STUDY SETTING Mediator role of the pattern and a Button class plays the This section describes the configuration of our empirical study. Colleague role. This study supplements the Hannemann and Kiczales work that is Figure 1 depicts the class diagram of the OO implementation of presented in Section 2.1. Section 2.2 uses the Mediator pattern to the Mediator pattern. The interfaces GUIMediator and illustrate the crosscutting property of some design patterns. GUIColleague are defined to realize the roles of the Mediator Section 2.3 introduces the metrics used in the assessment process. pattern. Specific application classes must implement these Section 2.4 describes our assessment procedures. interfaces based on the role that they need to play. In the example presented, the Button class implements the GUIColleague 2.1 Hannemann & Kiczales’ Study interface. The Label class implements the interface Several design patterns exhibit crosscutting concerns [9]. In this GUIMediator in order to manage the actions to be executed when context, Hannemann and Kiczales (HK) have undertaken a study buttons are clicked. Figure 1 also illustrates how the OO in which they have developed and compared Java [11] and implementation of the Mediator pattern is spread across the code AspectJ [2] implementations of the 23 GoF design patterns [5]. of the application classes. The shadowed attributes and methods They claim that programming languages affect pattern represent code necessary to implement the Colleague role of the implementation. Hence it is natural to explore the effect of aspect- Mediator pattern in the application context. oriented programming techniques on the implementation of the GoF patterns. For each of the 23 GoF patterns they developed a representative example that makes use of the pattern, and implemented the example in both Java and AspectJ. Design patterns assign roles to their participants; for example, the Mediator and Colleague roles are defined in the Mediator pattern. A number of GoF patterns involve crosscutting structures in the relationship between roles and classes in each instance of the pattern [9]. For instance, in the Mediator pattern, some operations Figure 1. The OO Design of the Mediator Pattern that change a Colleague must trigger updates to the corresponding Mediator; in other words, the act of updating crosscuts one or Figure 2 illustrates the source code of the Button class. The more operation in each Colleague in the pattern. necessary changes to implement the Colleague role are shadowed. The Button class implements the GUIColleague interface by Two kinds of pattern roles are identified in the HK study, which defining an attribute to reference a mediator (line 4) and the are called defining and superimposed roles. A defining role respective setMediator() method (line 6-8). Moreover, the defines a participant class completely. In other words, classes clicked() method of the Button class defines the functionality playing a defining role have no functionality outside the pattern. to communicate with the mediator (line 21). The unique role of the Façade pattern is an example of defining 01 public class Button extends JButton role. A superimposed role can be assigned to participant classes 02 implements GUIColleague { that have functionality outside of the pattern. An example of 03 04 private GUIMediator mediator; superimposed role is the Colleague role of the Mediator pattern, 05 since a participant class playing this role usually has functionality 06 public void setMediator(GUIMediator mediator){ 07 this.mediator = mediator; not related to the pattern. These kinds of roles are used by the 08 } authors to analyze the crosscutting structure of design patterns. 09 public Button(String name) { 10 super(name); In the HK study, the goal of the AspectJ implementations is to 11 this.setActionCommand(name); 12 this.addActionListener( modularize the pattern roles. The authors have reported that 13 new ActionListener() { modularity improvements
Load more

Recommended publications
  • (GOF) Java Design Patterns Mock Exams
    Gang of Four (GOF) Java Design Patterns Mock Exams http://www.JavaChamp.com Open Certification Plattform Authors: N. Ibrahim, Y. Ibrahim Copyright (c) 2009-2010 Introducing JavaChamp.com Website JavaChamp.com is an Open Certification Platform. What does this mean? JavaChamp is the best place to learn, share, and certify your professional skills. We help you develop yourself in the field of computer science and programming Here are the most significant features offered by JavaChamp: Online Exams Start Online Certification Exams in SCJP, SCEA, EJB, JMS, JPA and more... Top quality mock exams for SCJP, SCEA, EJB, JMS, JPA. Start Express or topic-wise customized exam. * We offer you unlimited free mock exams * Exams cover subjects like SCJP, SCEA, EJB, JMS, JPA,.. * You can take as many exams as you want and at any time and for no charges * Each exam contains 20 multiple choice questions * You can save the exams taken in your exams history * Your exams history saves the exams you took, the scores you got, time took you to finish the exam, date of examination and also saves your answers to the questions for later revision * You can re-take the same exam to monitor your progress * Your exams history helps the system to offer you variant new questions every time you take a new exam, therefore we encourage you to register and maintain an exams history Network Find guidance through the maze, meet Study-Mates, Coaches or Trainees... Studying together is fun, productive and helps you in building your professional network and collecting leads Bookshelf JavaChamp Bookshelf full of PDF eBooks..
    [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]
  • Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel
    Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel Kelt Dockins [email protected] Design Patterns in PHP and Laravel Kelt Dockins Dolph, Arkansas USA ISBN-13 (pbk): 978-1-4842-2450-2 ISBN-13 (electronic): 978-1-4842-2451-9 DOI 10.1007/978-1-4842-2451-9 Library of Congress Control Number: 2016961807 Copyright © 2017 by Kelt Dockins This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
    [Show full text]
  • Enterprise Development with Flex
    Enterprise Development with Flex Enterprise Development with Flex Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Enterprise Development with Flex by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Copyright © 2010 Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary E. Treseler Indexer: Ellen Troutman Development Editor: Linda Laflamme Cover Designer: Karen Montgomery Production Editor: Adam Zaremba Interior Designer: David Futato Copyeditor: Nancy Kotary Illustrator: Robert Romano Proofreader: Sada Preisch Printing History: March 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Enterprise Development with Flex, the image of red-crested wood-quails, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
    [Show full text]
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [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]
  • Behavioral Patterns
    Behavioral Patterns 101 What are Behavioral Patterns ! " Describe algorithms, assignment of responsibility, and interactions between objects (behavioral relationships) ! " Behavioral class patterns use inheritence to distribute behavior ! " Behavioral object patterns use composition ! " General example: ! " Model-view-controller in UI application ! " Iterating over a collection of objects ! " Comparable interface in Java !" 2003 - 2007 DevelopIntelligence List of Structural Patterns ! " Class scope pattern: ! " Interpreter ! " Template Method ! " Object scope patterns: ! " Chain of Responsibility ! " Command ! " Iterator ! " Mediator ! " Memento ! " Observer ! " State ! " Strategy ! " Visitor !" 2003 - 2007 DevelopIntelligence CoR Pattern Description ! " Intent: Avoid coupling the sender of a 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. ! " AKA: Handle/Body ! " Motivation: User Interfaces function as a result of user interactions, known as events. Events can be handled by a component, a container, or the operating system. In the end, the event handling should be decoupled from the component. ! " Applicability: ! " more than one object may handle a request, and the handler isn't known a priori. ! " Want to issue a request to one of several objects without specifying the receiver !" 2003 - 2007 DevelopIntelligence CoR Real World Example ! " The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver, by giving more than one object a chance to handle the request. ! " Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank.
    [Show full text]
  • JAVA CONCURRENCY ONLINE TRAINING – Java2aspire
    JAVA CONCURRENCY, JAVA PROFILING, THREAD POOLING, JAVA 8 Features, MAVEN and DESIGN PATTERNS ONLINE TRAINING By K.Ramesh Curriculum THREAD POOLING Day 01: Executor Framework 20 min Day 01: Java Profiling 10 min Day 01: Executor 10 min Day 01: ExecutorService 10 min Day 01: Executors 15 min Day 02: ThreadPoolExecutor 20 min Day 02: BlockingQueue 10 min Day 02: Callable vs Runnable 15 min Day 02: Future 15 min JAVA CONCURRENCY Day 03: ConcurrentHashMap 30 min Day 03: Producer Consumer 30 min Day 04: CountDownLatch 20 min Day 04: CyclicBarrier 20 min Day 04: Deadlock Condition 20 min Day 05: Race Condition 30 min Day 05: Semaphore 30 min JAVA 8 FEATURES Day 06: Lambda Expressions 40 min Day 06: Functional Interfaces 10 min Day 06: Functional Programming 10 min Day 07: Method References 10 min Day 07: Default Methods 40 min Day 07: Optional 10 min Day 08: Stream API 1 hour MAVEN Day 09: Project Object Model (POM) 20 min Day 09: Project Description 10 min Day 09: Public Repository 10 min Day 09: Dependency Management 10 min Day 09: Build Configuration 10 min Day 10: Installation 15 min Day 10: Dependency Scope 15 min Day 10: Proprietary Dependencies 15 min Day 10: Project Inheritance 15 min Day 11: Maven life cycle 20 min Day 11: Maven Directory Structure 20 min Day 11: Archetypes 20 min Day 12: Applications 1 hour DESIGN PATTERNS Day 13: Factory Pattern 20 min Day 13: Abstract Factory Pattern 10 min Day 13: Single Pattern 20 min Day 13: Prototype Pattern 10 min Day 14: Composite Pattern 10 min Day 14: Facade Pattern 15 min Day 14: DAO
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • A Survey of Design Pattern Based Web Applications
    JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2009 Vol. 8, No. 2, March-April 2009 A Survey of Design Pattern Based Web Applications Sridaran R, Campus Head, ICFAI National College, Vellore-632 006 India. Padmavathi G, Professor and Head, Department of Computer Science, Avinashilingam University for Women, Coimbatore-641 043, India. Iyakutti K, Senior Professor, School of Physics, Madurai Kamaraj University, Madurai-625 019, India. Abstract Pattern-based web applications have become popular since they promote reusability and consistency. In few cases, patterns do not produce the desired effect because of lack of experience in applying them. This situation forces one to think of a suitable re- engineering solution for such applications. The objectives of the paper are three fold. It provides a survey of different pattern-based web applications that will be useful for the application designers. It highlights some of the web applications where patterns have been inappropriately handled. A few re-engineering initiatives for such cases are also analyzed. Key Words: Patterns, Web Applications, Re-engineering, Hypermedia, Semantic web, Partitioning. 1 INTRODUCTION Web application designers need to address many challenges during development in order to comply the quality of service requirements including speed, scalability and security. In recent years numerous non-web based applications have been re-written as web based because of the ever growing business needs. These migration activities are much more complicated and time consuming than a new software development. Most of these challenges are with data handling, organizing, or structuring of the web applications.
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]
  • Python in Practice
    Python in Practice Create Better Programs Using Concurrency, Libraries, and Patterns Mark Summerfield AAddison-Wesley Upper Saddle River, NJ • Boston • Indianapolis • San Francisco New York • Toronto Montreal • London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City Contents Foreword xiii Introduction 1 Acknowledgments 3 Chapter 1. Creational Design Patterns 5 1.1. Abstract Factory Pattern 5 1.1.1. A Classic Abstract Factory 6 1.1.2. A More Pythonic Abstract Factory 9 1.2. Builder Pattern 11 1.3. Factory Method Pattern 17 1.4. Prototype Pattern 24 1.5. Singleton Pattern 26 Chapter 2. Structural Design Patterns 29 2.1. Adapter Pattern 29 2.2. Bridge Pattern 34 2.3. Composite Pattern 40 2.3.1. A Classic Composite/Noncomposite Hierarchy 41 2.3.2. A Single Class for (Non)composites 45 2.4. Decorator Pattern 48 2.4.1. Function and Method Decorators 48 2.4.2. Class Decorators 54 2.4.2.1. Using a Class Decorator to Add Properties 57 2.4.2.2. Using a Class Decorator Instead of Subclassing 58 2.5. Facade Pattern 59 2.6. Flyweight Pattern 64 2.7. Proxy Pattern 67 Chapter 3. Behavioral Design Patterns 73 3.1. Chain of Responsibility Pattern 74 3.1.1. A Conventional Chain 74 3.1.2. A Coroutine-Based Chain 76 3.2. Command Pattern 79 ix 3.3. Interpreter Pattern 83 3.3.1. Expression Evaluation with eval() 84 3.3.2. Code Evaluation with exec() 88 3.3.3. Code Evaluation Using a Subprocess 91 3.4. Iterator Pattern 95 3.4.1.
    [Show full text]