DOCSLIB.ORG

Design Pattern Contracts

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Pattern Contracts DESIGN PATTERN CONTRACTS DISSERTATION Presented in Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the Graduate School of The Ohio State University By Jason O. Hallstrom, B.S., M.A., M.S. ***** The Ohio State University 2004 Dissertation Committee: Approved by Neelam Soundarajan, Adviser Anish Arora Adviser Bruce W. Weide Department of Computer Science and Engineering c Copyright by Jason O. Hallstrom 2004 ABSTRACT A design pattern describes a commonly recurring problem in the design of object- oriented software, a solution to that problem, and the context in which the solution can be applied. The benefits of design patterns are two-fold. First, patterns serve as guidance to the novice designer. Second, they provide an extended vocabulary for documenting software design. In the mid 1990s, the publication of several pattern cat- alogs – compendiums of design patterns – popularized patterns as a tool for designing object-oriented software. Today, many of these catalogs are standard references, and the patterns they contain are an important part of software practice. Unfortunately, the descriptive format popularized by these catalogs is inherently imprecise. As a consequence, it is unclear when a pattern has been applied correctly, or what can be concluded about a system implemented using a particular pattern. This ambiguity threatens to undermine the two principal benefits associated with the use of design patterns. First, novice designers are more prone to error without a precise description of how each pattern must be applied. Second, documentation describing the patterns applied in designing a system may be misleading, as different designers can interpret pattern descriptions in subtly different ways. To address the ambiguity issues associated with design pattern descriptions, we introduce the concept of a design pattern contract as a formalism for precisely spec- ifying design patterns. Like all contracts, a design pattern contract consists of two ii primary components: a responsibilities component and a rewards component. The responsibilities component of a pattern contract precisely characterizes the require- ments that must be satisfied by the designer when applying a particular pattern. The rewards component specifies the system properties that are guaranteed to be exhibited if the contract responsibilities are indeed satisfied. The contract formalism alone, however, is not enough to guarantee that design pat- terns will be applied correctly. After all, software design is a complex task. Even when guided by a precise set of requirements, designers can — and do — make mistakes. To detect such contract violations, we introduce the notion of a contract monitor — an executable unit of deployment used to detect runtime contract violations. During the testing phase of a system’s life cycle, the designer can instrument the system with the appropriate monitors to determine if the contracts used in its construction were applied correctly. We present two approaches to implementing these monitors. The choice of which to use depends on the requirements of the system, and the skill-set of the designer. iii To my family. iv ACKNOWLEDGMENTS During the last six years at Ohio State, I have been fortunate to be involved with a number of people that have encouraged, mentored, and inspired me. First, I would like to express my sincerest gratitude to my advisor, Neelam Soundarajan. Neelam has been closely involved with every aspect of the work presented in this dissertation, and there isn’t a single chapter that doesn’t benefit from his insights. He has been an excellent advisor and friend, and I appreciate his efforts tremendously. I would also like to thank Anish Arora, Bruce Weide, and Bill Leal, who have been my unofficial co-advisors throughout the years. They have provided invaluable guidance and support, and have taken a personal interest in my success. These gents — my four advisors — are constant reminders of why I wanted to become a professor, and the relationships that I hope to build with my own students. I am also grateful to the numerous graduate student colleagues that have shared this experience with me. In particular, I would like to thank the student members of the Reusable Software Research Group — Nigamanth Sridhar, Scott Pike, Hilary Pike, Christopher Bohn, Ben Tyler, and Michael Gibas — as well as the student members of the Dependable Distributed and Networked Systems Group — Santosh Kumar, Murat Demirbas, Hongwei Zhang, Sandip Bapat, Vinayak Naik, Vinod Kulathumani, and Prabal Dutta. These folks have all provided valuable assistance at some point or another, and have helped to make my time at OSU a period that I will look back on v with fond memories. I am especially thankful for my friendships with Nigamanth and Scott. The “team support” that they have shown throughout the years has made a tremendous difference during a number of difficult times. I will dearly miss our late night research sessions in the halls of Dreese Labs — aerobie and foosball included. I would also like to express my gratitude to the remaining members of the Reusable Software Research Group — Bill Ogden, Paolo Bucci, Tim Long, Bob Mathis, Wayne Heym, and Joan Krone. This group has been instrumental in helping me to develop my research and presentation skills — not to mention, toughening my skin. On the other side of the fence — outside of graduate school — I have also been blessed with a team of supporters for whom I am grateful. I would like to thank my friends from Metavante — Bob Stoll, Ruth Wollan, Bastian Knoppers, and many others — for sticking with me throughout the years, despite a schedule that made their lives difficult. I would like to especially thank Bob, who has been a dear friend and mentor, and provides one of the best examples of personal integrity that I know of. I feel very fortunate to have worked with the Willowbrook team, and I count the experience as instrumental in my academic success. I also owe a debt of gratitude to my longtime friend, Adam Foit, whose friendship has been a source of great joy for many years. I am thankful not only for his friendship and laughter, but for his willingness to persist in his efforts to keep in contact, despite my tendency to disappear for months at a time. He has been an invaluable ally, and I want to express my most sincere appreciation. Throughout this process, and throughout my life, I have been supported by the unwavering love and encouragement of my wonderful parents, Duane and Barbara Hallstrom. Their confidence in me has always surpassed my confidence in myself, and vi as a result, I’ve been able to reach goals — humble as they might be — that once seemed unattainable. From the very beginning, that’s how it’s always been — my parents have encouraged me to excel beyond the vision that I had for myself. I can never thank them enough for all that they have done, and for the life that they have made possible for me. I would also like to thank the rest of my family — who are too numerous to name individually — for their love and encouragement, as well as the interest that they’ve shown in my academic career. I have dedicated my dissertation work to them, because being a part of the Hallstrom family is the thing of which I am most proud. Last, but certainly not least, I want to thank my fianc´e,Kimberly Rose, for her unconditional love, laughter, and friendship. She is a reminder to me of all that is good within us, and all that I aspire to be. I could not have accomplished this task without her support, nor would I have been inclined to. Kimberly is my best friend, my love, and my life. vii VITA May 4, 1976 . Born – Palos Heights, Illinois June 2004 . M.S. Computer Science & Engineering, The Ohio State University August 1998 . .M.A. Economics, Miami University May 1998 . .B.S. Systems Analysis, Miami University January 2002 – present . Graduate Research Associate, The Ohio State University September 1998 – December 2001 . .Graduate Teaching Associate, The Ohio State University August 1995 – present . Independent Systems Consultant PUBLICATIONS Research Publications Neelam Soundarajan and Jason O. Hallstrom. Responsibilities and rewards: Specify- ing design patterns. In Proceedings of the 26th International Conference on Software Engineering (ICSE’04), pages 666–675. IEEE Computer Society Press, May 2004. Jason O. Hallstrom, Nigamanth Sridhar, Paolo A.G. Sivilotti, Anish Arora, and William M. Leal. A container-based approach to object-oriented product lines. Jour- nal of Object Technology, vol. 3, no. 4, pages 309–326. April 2004. Jason O. Hallstrom, William M. Leal, and Anish Arora. Scalable evolution of highly- available systems. IEICE/IEEE Joint Special Issue on Assurance Systems and Net- works, E86-B(10), pages 2154–2166. October 2003. viii Arjav J Chakravarti, Xiaojin Wang, Jason O. Hallstrom, and Gerald Baumgartner. Implementation of strong mobility for multi-threaded agents in Java. In Proceedings of the 2003 International Conference on Parallel Processing (ICPP’03), pages 321– 330. IEEE Computer Society Press, October 2003. Nigamanth Sridhar and Jason O. Hallstrom. Generating configurable containers for component-based software. In Proceedings of the 6th Workshop on Component-Based Software Engineering (CBSE6). Portland OR, May 2003. Jason O. Hallstrom and Neelam Soundarajan. Incremental development using object- oriented frameworks: A case study. Journal of Object Technology, vol. 1, no. 3, pages 189–205, July 2002. Jason O. Hallstrom, Scott M. Pike, and Nigamanth Sridhar. Iterators reconsid- ered. In Proceedings of the 5th Workshop on Component-Based Software Engineering (CBSE5). Orlando FL, May 2002. Xiaojin Wang, Jason O. Hallstrom, and Gerald Baumgartner. Reliability through strong mobility. In Proceedings of the 7th ECOOP Workshop on Mobile Object Systems (MOS’01). Budapest Hungary, June 2001. FIELDS OF STUDY Major Field: Computer Science and Engineering Studies in: Software Methodology Prof.
Load more

Recommended publications
  • 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]
  • 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]
  • 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]
  • 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]
  • Java Design Patterns I
    Java Design Patterns i Java Design Patterns Java Design Patterns ii Contents 1 Introduction to Design Patterns 1 1.1 Introduction......................................................1 1.2 What are Design Patterns...............................................1 1.3 Why use them.....................................................2 1.4 How to select and use one...............................................2 1.5 Categorization of patterns...............................................3 1.5.1 Creational patterns..............................................3 1.5.2 Structural patterns..............................................3 1.5.3 Behavior patterns...............................................3 2 Adapter Design Pattern 5 2.1 Adapter Pattern....................................................5 2.2 An Adapter to rescue.................................................6 2.3 Solution to the problem................................................7 2.4 Class Adapter..................................................... 11 2.5 When to use Adapter Pattern............................................. 12 2.6 Download the Source Code.............................................. 12 3 Facade Design Pattern 13 3.1 Introduction...................................................... 13 3.2 What is the Facade Pattern.............................................. 13 3.3 Solution to the problem................................................ 14 3.4 Use of the Facade Pattern............................................... 16 3.5 Download the Source Code.............................................
    [Show full text]
  • Table of Contents
    Table of Contents ± -—T^jTp^om Object-Oriented to Functional Programming 5 Chajava- an introduction 5 java programming paradigms 6 CO imperative programming CD Real-life imperative example Object-oriented paradigm 7 Objects and classes 7 Encapsulation 7 Abstraction 8 Inheritance 8 Polymorphism 9 Declarative programming 10 Functional programming 11 Working with collections versus working with streams 11 An introduction to Unified Modeling Language 12 Class relations 14 Generalization 15 Realization 15 Dependency 16 Association 16 Aggregation 16 Composition 17 Design patterns and principles 17 Single responsibility principle 18 Open/closed principle 20 Liskov Substitution Principle 20 Interface Segregation Principle 22 Dependency inversion principle 23 Summary 24 Chapter 2: Creational Patterns 27 Singleton pattern 27 Synchronized singletons 29 Synchronized singleton with double-checked locking mechanism 30 Lock-free thread-safe singleton 30 tu * y and lazy loacling 31 i he factory pattern 31 Simple factory pattern 32 Table of Contents Static factory 33 Simple factory with class registration using reflection 34 Simple factory with class registration using Product.newlnstance 35 Factory method pattern 36 Anonymous concrete factory 38 Abstract factory 38 Simple factory versus factory method versus abstract factory 40 Builder pattern 40 Car builder example 41 Simplified builder pattern 43 Anonymous builders with method chaining 44 Prototype pattern 45 Shallow clone versus deep clone Object pool pattern Summary аэоэсБ Chapter 3: Behavioral Patterns
    [Show full text]
  • Security Pattern Validation and Recognition
    Security-Pattern Recognition and Validation Dissertation Submitted by Michaela Bunke on 12th December 2018 to the Universit¨atBremen Faculty of Mathematics and Computer Science in partial fulfillment of the requirements for the degree of Doktor der Ingenieurwissenschaften { Dr.-Ing. { Reviewed by Prof. Dr. Hans-J¨orgKreowski Universit¨atBremen, Germany and Dr. Karsten Sohr Universit¨atBremen, Germany In Memorial of Ilse Schlamilch Karl Schlamilch Manfred Friedrichs 21 November 1924 03 March 1927 29 August 1935 09 June 2017 19 June 2018 3 July 2017 ABSTRACT The increasing and diverse number of technologies that are connected to the Internet, such as distributed enterprise systems or small electronic devices like smartphones, brings the topic IT security to the foreground. We interact daily with these technologies and spend much trust on a well-established software development process. However, security vulnerabilities appear in software on all kinds of PC(- like) platforms, and more and more vulnerabilities are published, which compromise systems and their users. Thus, software has also to be modified due to changing requirements, bugs, and security flaws and software engineers must more and more face security issues during the software design; especially maintenance programmers must deal with such use cases after a software has been released. In the domain of software development, design patterns have been proposed as the best-known solutions for recurring problems in software design. Analogously, security patterns are best practices aiming at ensuring security. This thesis develops a deeper understanding of the nature of security patterns. It focuses on their validation and detection regarding the support of reviews and maintenance activities.
    [Show full text]
  • Design Patterns Mock Test
    DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT http://www.tutorialspoint.com Copyright © tutorialspoint.com This section presents you various set of Mock Tests related to Design Patterns Framework. You can download these sample mock tests at your local machine and solve offline at your convenience. Every mock test is supplied with a mock test key to let you verify the final score and grade yourself. DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT IIII Q 1 - Which of the following describes the Composite pattern correctly? A - This pattern builds a complex object using simple objects and using a step by step approach. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 2 - Which of the following describes the Decorator pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 3 - Which of the following describes the Facade pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure.
    [Show full text]
  • 2010 Midterm Exam Answer All 10 Questions. Answer Essay Questions
    2010 Midterm Exam Answer all 10 questions. Answer essay questions as briefly as possible. The following might be names of patterns: Abstract Class, Abstract Factory, Adapter, Application Controller, Bridge, Builder, Chain of Responsibility, Collaborator, Command, Composite, Decorator, Façade, Factory Method, Flyweight, Interpreter, Iterator, Master- Slave, Mediator, Memento, Null Object, Observer, Prototype, Proxy, Singleton, Specification, State, Strategy, Template Method, Visitor. 1. The purpose of many of the design patterns is to make it easy to change some property of the system. What design pattern would you use to make it easy to change: A. The algorithm that an object uses. B. The class of the object that a method returns. C. The kind and number of objects that react to changes in the object you are designing. D. Adding operations to classes without changing the class. E. How methods in a class behave. 2. What is a code smell? List two code smells. 3. Explain shallow copy and deep copy. 4. Explain control coupling. Give an example. 5. Explain Coupling and Cohesion. 6. According to the Big Ball of Mud paper why should we use piecemeal growth? 7. Explain the command processor pattern. 8. What is the difference between the Proxy and Decorator pattern? 9. Explain how the State pattern works. 10.What are some of the problems cause by using the singleton pattern? 2010 Final Exam Answer all 10 questions. Answer essay questions as briefly as possible. The following might be names of patterns: Abstract Class, Abstract Factory, Active Object Model, Adapter, Application Controller, Bridge, Builder, Chain of Responsibility, Collaborator, Command, Composite, Decorator, Dependency Injection, Dynamic Factory, Façade, Factory Method, Flyweight, Interpreter, Iterator, Master-Slave, Mediator, Memento, Null Object, Observer, Property, Prototype, Proxy, Singleton, Schema, Smart Variables, Specification, State, Strategy, Template Method, Type Object, Visitor.
    [Show full text]
  • Design Patterns (Factory, Memento, Flyweight, Prototype)
    Factory pattern Acknowledgement: Head-first design patterns 461 Pizza Store public class PizzaStore{ Pizza orderPizza() { Pizza pizza = new Pizza(); pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } } If you need more than one type… Pizza orderPizza(String type) { Pizza pizza ; if (type.equals(“cheese”)) { pizza = new CheesePizza(); } else if (type.equals(“greek”)) { pizza = new GreekPizza(); } else if (type.equals(“pepperoni”)) { pizza = new PepperoniPizza(); } pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } still more… Pizza orderPizza(String type) { Pizza pizza; if (type.equals(“cheese”)) { 1. Dealing with which pizza = new CheesePizza(); concrete class is being } else if (type.equals(“greek”)) { pizza = new GreekPizza(); instantiated } else if (type.equals(“pepperoni”)) { pizza = new PepperoniPizza(); 2. Changes are } else if (type.equals(“chicken”)) { pizza = new ChickenPizza(); preventing orderPizza() } else if (type.equals(“veggie”)) { from being closed for pizza = new VeggiePizza(); } modification pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } Building a simple Pizza factory Pizza orderPizza(String type) { public class SimplePizzaFactory{ public Pizza createPizza (String type) { Pizza pizza; Pizza pizza = null; pizza.prepare(); if (type.equals(“cheese”)) { pizza = new CheesePizza(); pizza.bake(); } pizza.cut(); else if (type.equals(“pepperoni”)) { pizza.box(); pizza = new PepperoniPizza(); return pizza; } } else if (type.equals(“chicken”)) { pizza = new
    [Show full text]
  • Towards Pluggable Design Patterns Utilizing Package Templates Eyvind
    Towards Pluggable Design Patterns Utilizing Package Templates Eyvind W. Axelsen and Stein Krogdahl University of Oslo Department of Informatics {eyvinda, steinkr}@ifi.uio.no Abstract In this paper, we show how package templates, a new mechanism for code modularization, may be utilized to create reusable packages for selected design patterns that can be plugged into an existing architecture with a minimum of “glue code”. Exemplified through these implementations we consider some desirable extensions to the previously published version of the mechanism. 1 Introduction The concept of design patterns [9] is an approach to object oriented design and development that attempts to facilitate the reuse of conceptual solutions for common functionality required by certain patterns or classes of common problems. As such, they seem like a perfect candidate for inclusion as reusable components in frameworks, be they completely general such as e.g. the .NET framework [17] or application specific. However, it seems that even though the concepts of many patterns are in relative widespread use, implementing them as reusable components in mainstream languages like C# [6] or Java [11] is hard. This is at least in part due to limitations with regards to e.g. extensibility of the subtyping relation [19] and/or lack of support for mechanisms dealing with crosscutting concerns. A few existing papers explicitly discuss new language concepts in the context of implementing design patterns, notably one by Hannemann and Kiczales [10] utilizing AspectJ [2, 5], and one by Mezini and Ostermann [16] utilizing the Caesar system [1]. The package template (PT) mechanism [12, 13] targets the development of collections of reusable interdependent classes.
    [Show full text]