DOCSLIB.ORG

Design Patterns” *

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Patterns” * Example of a Pattern Software ! Composite Pattern ! Previous UML: Item “Design Patterns” * Atom Container What started it And then came ... •(aka “Gang of four”) Two books on architecture, by Christopher Alexander, et al. Does not use UML, uses earlier Booch Notation CS 121 Patterns Links (http://www.cs.hmc.edu/courses/2001/spring/cs121/patterns.html) Definition of a Pattern ! Patterns Home Page ! Introduction to Patterns (emphasis on Alexander) ! Carleton Pattern Repository ! Design Patterns, Pattern Languages, and Frameworks (Douglas Schmidt) ! a solution to a recurrent problem ! Essential Software Design Patterns (Walter F. Tichy) ! Patterns in Ja va AWT ! Design Patterns in Dynamic Programming (Peter Norvig) ! The Tao of Design (John Schettino) ! not a “concrete” solution, but an ! Source Code for GoF book ! GoF Pattern Template ! IAP '97 abstract version of it ! Pattern Depot ! Design Patterns, an unbiased assessment (Bryan Dudash) ! Patterns and Software: Essential Concepts and Terminology (with links) (Brad Appleton) ! four essential elements: ! Big Ball of Mud ! Scott Ambler's Writings ! A Pattern Language for Pattern Writing (Gerard Meszaros, Jim Doble) ! Name of the Pattern ! Synopses (Mark Grand) ! UML@Work - From Analysis to Implementation (Hitz, Kappel, Retschitzegger) ! Human-Com puter Interface (HCI) Patterns (Jenifer Tidwell) ! Roundabout, a Pattern Language for Recursive Programming (Eugene Wallingford) ! The Problem ! Loop Patterns (Owen Astrachan, Eugene Wallingford) ! Object Recursion (Bobby Woolf) ! A Development Process Generative Pattern Language (James O. Coplien) ! The Solution ! Papers on patterns and HCI (Human-Computer Interfaces) ! Pedagogical Patterns ! AntiPatterns tutorial ! Consequences, tradeoffs ! Antipatterns of Scholarship ! Cetus Links Uses of Patterns Patterns are not ... ! Conversational “handle” on which to ! Classes hang ideas and concepts ! Libraries ! To direct the user to a known solution ! Reusable packages for a kind of problem ! Higher-order functions (?!) ! To help focus a design ! As a vehicle for refining solution techniques Examples of Patterns Example: Composite Pattern ! “Design Patterns” book lists 23 patterns, ! Name: Composite in several categories. ! The Problem: Construct a class of ! These are sometimes annotated GoF objects wherein (“Gang of Four”). ! objects can either be indivisible or have multiple components. ! Many others have contributed additional ! a collection of components can be treated patterns. as a single object by a client. ! The Solution: The one we have shown ! Consequences, tradeoffs Non-Recursive Examples of Composite Patterns Composite Pattern UML Whole ! Drawing program shape: rectangle, oval, group: set of shapes ! File systems, files, directories, links ! S expressions PartType1 PartType2 PartType3 SubPartType1 SubPartType2 Tradeoffs in Patterns to be Discussed Composite Pattern (alphabetized) ! Whether recursive structure is needed, or will “flat” ! Adapter ! Memento structure suffice ! Cache ! Model-View-Controller ! Whether ordering of components is significant ! Composite ! Observer ! Whether components refer back to parents ! Decorator ! Proxy ! Whether components can be shared ! Delegation ! Singleton ! Who should delete the children ! Façade ! State ! Whether children are represented as a list or simply ! Interface ! Stream enumerated ! Iterator ! Visitor ! Data structure issues (whether to use struct, array,linked list, etc.) Iterator Pattern Iterator Pattern UML ! (GoF, p 257) aka Cursor Pattern Iterator * Container first() ! provides a way to enumerate the elements in next() Interfaces a Composite without exposing the internal current() createIterator() structure of the implementation. done() ! There can be multiple Iterators on a given container. anIterator * aContainer ! Example: In Java, the Enumeration and first() Implementation next() Iterator interfaces do this. In STL, there are current() createIterator() templates for many iterator classes. done() Iterator Pattern in C++ STL Iterator Pattern in Java ! General ! C++: ! Informal ! Java: Methods: Container<Type>::Iterator myIterator; Methods: Enumeration e = container.elements(); ! first() ! myIterator = container.begin(); ! first() ! (implied in initialization) ! next() ! myIterator++; ! next() ! nextElement() ! done() ! myIterator == container.end(); ! ! done() ! hasMoreElements() ! current() ! *myIterator ! currentItem() ! (none- save result of nextElement()) ! Syntax is that of a pointer Exercise Visitor Pattern ! (GoF, p 331) ! Consider a composite that structures its elements as directed, ordered, tree. ! Similar to the Iterator pattern, except that rather than passing objects outside during the enumeration, a Visitor object ! What kinds of iterators are possible? is passed into the Container. ! ! What are the methods on each iterator? The Visitor works on the objects while inside the Container. ! Can add new operations without changing structure of elements. Visitor Pattern UML Visitor in C++ ! class Container<Type> { Visitor * Container next() Interface acceptVisitor(Visitor<Type>); visit() …. acceptVisitor() done() } ! class Visitor<Type> { aVisitor<T> * aContainer<T> visit(<Type> Thing); // Do something to Thing next(); // Advance to the next. next() Implementation boolean done(); // Tell if no more things. visit(T) acceptVisitor() done() } Exercise Façade Pattern ! (GoF, p 185) ! What are the relative Advantages of ! An entire sub-system or set of classes, etc. is Visitor vs. Iterator? given a single simple interface ! Problems solved: ! shield the user against the internal complexity of how the classes are used together ! bundle less-coupled components Façade Pattern Example Façade Pattern VisualTool ! In building using a façade pattern, it is important that the individual components not drawShape() addText() depend on the façade itself. ! This would introduce cross-coupling, which is undesirable. ! Preferably they don’t depend on each other ShapeDrawer TextEditor either. ! When the façade is “removed”, the components should “fall apart” as their original, uncoupled or loosely-coupled, entities. Rather than Make the Façade a Single Class, A Package could be used as a Façade ! A package is a group of related classes. Brief Digression on ! Packages can have sub-packages. Packages ! Visibility can be controlled. UML Package Notation designates inter-package dependency Packages/Dependency notation in UML Coupling / Cohesion Terminology Dependency Company ! Two packages (or classes, for that Sales Accounting matter) between which there is a high- degree of interplay are said to be strongly-coupled. Marketing Shipping ! Strong coupling is considered undesirable; loosely-coupled is better for packages and classes. Coupling / Cohesion Terminology Coupling / Cohesion Summary ! A set of methods for a class, or classes ! Coupling is bad. in a package, are said to be cohesive (or “coherent”) if they provide aspects of ! Cohesion (coherence) is good. a uniform model for dealing with the objects / classes. ! Cohesiveness is desirable; it is a mark of a careful design. A Portion of a About Packages Java Package Hierarchy ! Innermost packages contain classes jav a.ne t jav a. rmi ! Cyclic dependencies among packages jav a. rmi .a ctiv atio n should be avoided: break them, or combine jav a. rmi .dgc into a single package. jav a. rmi .r egis try ! Packages can help delineate work- jav a. rmi .s erve r breakdown among teams, and can thus serve jav a.se cur ity as a management device jav a.se cur ity. acl jav a.se cur ity. cert ! Consider Java package construct. jav a.se cur ity. inte rfa ces ! Equivalent in C++ is namespaces jav a.se cur ity. spec Namespaces in C++ C++ Namespace Example ! Without Namespaces, there is, in effect, one big flat name space. ! The danger is conflicting names in DB two parallel RT namespaces different modules and name space “pollution” by modules with lots of names. sub- OODB RDB namespaces ! Namespace construct allows structuring object-oriented relational into an arbitrary number of hierarchical databases databases levels. realtime databases C++ Namespace Example nam espa ce D B nam espa ce R T qualified names { { c lass A n ames pace OODB { { cla ss A }; RT: :A DB: :OOD B::A } { } ; Returning to Patterns } non-conflicting n ames pace RDB DB: :RDB ::A { cla ss A { }; } } Decorator Pattern Decorator Class Structure ! (GoF, p 175) ! At least three possibilities: ! aka Wrapper (one version thereof) ! The decorating class inherits from the decorated class (“direct” decoration). ! Enclose an object of one class in another class that “decorates” the ! The decorating class aggregates or composes a member of the decorated original objects (e.g. scrollbars or a class (“decoration by delegation”). border around a window). ! A third class aggregates or composes ! Examples: streams of various types both the decorated class and the (OutputStream, FileOutputStream, decoration. PrintStream, …) Adapter Pattern Adapter Pattern based on Association ! (GoF, p 139) Pre-Existing ! aka Binding, Wrapper (another version) Target Adaptee Client ! Adapts one or more existing APIs to fit Request() ExistingRequest() another API specification (one that adaptee Association clients expect). Interface inheritance Adapter ! (API = Application Programming Request() Interface) Adapter Pattern Adapter Example based on Association ! An interface defines a Stack. ! A dynamic array implementation defines Stack Array Client an Array. push() addItem() ! An adapter defines an ArrayStack,
Load more

Recommended publications
  • Component Design Recall: Problem with Subclassing
    the gamedesigninitiative at cornell university Lecture 8 Component Design Recall: Problem with Subclassing Games have lots of classes Each game entity is different NPC Needs its own functionality (e.g. object methods) Human Orc Want to avoid redundancies Makes code hard to change Common source of bugs Human Human Orc Orc Warrior Archer Warrior Archer Might be tempted to subclass Common behavior in parents Redundant Behavior Specific behavior in children the gamedesigninitiative 2 Architecture Patterns at cornell university Recall: Problem with Subclassing Games have lots of classes Each game entity is different NPC Needs its own functionality (e.g. object methods) Warrior Archer Want to avoid redundancies Makes code hard to change Common source of bugs Human Orc Human Orc Warrior Warrior Archer Archer Might be tempted to subclass Common behavior in parents Redundant Behavior Specific behavior in children the gamedesigninitiative 3 Architecture Patterns at cornell university Alternative: Decorator Pattern New Functionality OriginalReference to Original Request Decorator Object Functionalitybase object Object the gamedesigninitiative 4 Architecture Patterns at cornell university Alternate: Delegation Pattern Original Reference to Request Delegate Object delegate Object Forward Request Inversion of the Decorator Pattern the gamedesigninitiative 5 Architecture Patterns at cornell university Issues with Static Typing Method in original class Original object class obj.request(arg1,…, argn) Original Reference to Request Delegate
    [Show full text]
  • Game Architecture Revisited Recall: the Game Loop
    the gamedesigninitiative at cornell university Lecture 8 Game Architecture Revisited Recall: The Game Loop Receive player input Process player actions Update 60 times/s Process NPC actions Interactions (e.g. physics) = 16.7 ms Cull non-visible objects Transform visible objects Draw Draw to backing buffer Display backing buffer the gamedesigninitiative 2 Architecture Revisited at cornell university The Game Loop Receive player input Process player actions Update Process NPC actions Interactions (e.g. physics) Almost everything is in loop Draw Except asynchronous actions Is enough for simple games How do we organize this loop? Do not want spaghetti code Distribute over programmers the gamedesigninitiative 3 Architecture Revisited at cornell university Model-View-Controller Pattern Controller Calls the • Updates model in methods of response to events • Updates view with model changes Model View • Defines/manages • Displays model the program data to the user/player • Responds to the • Provides interface controller requests for the controller the gamedesigninitiative 4 Architecture Revisited at cornell university The Game Loop and MVC Model: The game state Value of game resources Location of game objects Update View: The draw phase Rendering commands only Major computation in update Draw Controller: The update phase Alters the game state Vast majority of your code the gamedesigninitiative 5 Architecture Revisited at cornell university Application Structure Root Controller Ownership Subcontroller Subcontroller View Model Model
    [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 Specification for Delegation and Incentives in Cardano
    Engineering Design Specification for Delegation and Incentives in Cardano–Shelley AN IOHK TECHNICAL REPORT Philipp Kant Lars Brunjes¨ Duncan Coutts [email protected] [email protected] [email protected] [email protected] April 11, 2019 Abstract This document describes the requirements and design for a delegation and incentives mechanism to be used in the Shelley release of Cardano. List of Contributors Lars Brunjes,¨ Jared Corduan, Duncan Coutts, Philipp Kant, Dimitris Karakostas, Aggelos Kiayias, Elias Koutsoupias, Mario Larangeira, Damian Nadales, Aikaterini-Panagiota Stouka. Contents 1 Purpose 4 2 Requirements 5 2.1 Functional Requirements . .5 2.1.1 Proof of Eligibility . .5 2.1.2 Visibility of Delegation on the Blockchain . .5 2.1.3 Restricting Chain Delegation . .5 2.1.4 Cheap Re-Delegation . .5 2.1.5 Neutral Addresses . .5 2.2 Security Requirements . .6 2.2.1 Sybil Attack Protection at Stake Pool Level . .6 2.2.2 Address Non-malleability . .6 2.2.3 Public Spending Keys Should not be Disclosed Prematurely . .6 2.2.4 Mitigate Key Exposure . .6 2.2.5 Handle Inactive Stake Pools . .6 2.2.6 Avoid Hard Transition . .6 2.2.7 Change Delegation Without Spending Key . .7 2.3 Non-functional Requirements . .7 2.3.1 Asymptotic space and time complexity . .7 2.3.2 Minimise economic attacks . .7 2.4 Requirements to Preserve Existing Features . .7 2.4.1 Master Recovery Key . .7 1 2.4.2 Address Recognition . .7 2.4.3 Wallet should be Runnable on Independent Devices . .7 2.4.4 Maintain Privacy .
    [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]
  • Title: Foundation Patterns Authors: Dwight Deugo E-Mail: Deugo@Scs
    Title: Foundation Patterns Authors: Dwight Deugo E-mail: [email protected] Address: School of Computer Science Carleton University 1125 Colonel By Drive Ottawa, Ontario, Canada, K1S 5B6 Telephone: (613) 520-2600 ext. 8438 (613) 520-4333 Fax: (613) 520-4334 Abstract: Many patterns depended on one important distinction: the distinction between an object's class and its type. For example, many patterns rely on interface inheritance, although, on examining their structures, most are described using implementation inheritance. The making of this implicit distinction gives evidence that there are patterns, fundamental to many, that live within other patterns and are at the foundation of good object-oriented principles. I give these patterns the name foundation patterns. I discuss two such foundation patterns: delegation and substitution, separating the two into their rightful positions, making clear what each patterns' role is in object-oriented design. Foundation Patterns Dwight Deugo [email protected] School of Computer Science Carleton University Introduction Although not mentioned, many patterns depend on one important distinction. This is the distinction between an object's class and its type. Stated another way, these patterns rely on interface inheritance rather than on implementation inheritance. Nevertheless, on examining their structures, most pattern descriptions use implementation inheritance. This is not surprising, since languages like Smalltalk and C++ do not explicitly support the notion of a type or a subtype within the language. Java is the exception to this, directly supporting interfaces and their inheritance, bringing attention to these well deserving topics. The making of this implicit distinction gives evidence that there are other patterns, fundamental to many, if not all patterns, which are either assumed and undocumented or still waiting to be discovered.
    [Show full text]
  • The Use of Design Pattern on Informatics Engineering Students Thesis
    Advances in Intelligent Systems Research (AISR), volume 157 Mathematics, Informatics, Science, and Education International Conference (MISEIC 2018) The Use of Design Pattern on Informatics Engineering Students Thesis Alifah Diantebes Aindra, Aim Abdulkarim Eki Nugraha Oktarica Pratiwi Suryoningtyas, Department of Civil Education Department of Computer Science and Aji Prasetya Wibawa Universitas Pendidikan Indonesia Universitas Pendidikan Indonesia Department of Vocational Education Bandung, Indonesia Bandung, Indonesia Universitas Negeri Malang [email protected] [email protected] Malang, Indonesia [email protected], [email protected], [email protected] Abstract— University students should write a thesis to get the process of software development to reduce the development their undergraduate (Bachelor) degree is. Most Informatics process so that students can complete their thesis quickly. By engineering students of the Electrical Engineering reducing the development time of a software, it can also reduce Department in Universitas Negeri Malang use research and the costs during the production process [1]. One of these development method for their thesis. There are many solutions is to use design patterns for the development. The use solutions or methods in software engineering which aim to of a design pattern can reduce the development time, facilitate develop a good quality software. One of these solutions is communication between the development team, written source using design patterns. Several benefits of using the design code becomes more flexible and easy to reuse [2]. patterns are; decreasing time of production, having a Unlike the above mentioned, to implement or adapt the reusable and flexible code, and making people easier to design pattern, a proper and good preparation from the understand.
    [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]
  • Object-Oriented Desgin Flyweight Pattern George Blankenship 1
    Object-Oriented Desgin Flyweight Pattern CSCI 253 Object Oriented Design: Flyweight Pattern George Blankenship Flyweight Pattern George Blankenship 1 Overview Creational Patterns Structural Patterns Behavioral Patterns Singleton Composite Chain of Respons. Abstract factory Façade Command Factory Method Proxy Interpreter Prototype Flyweight Iterator Builder Mediator Adapter Memento Bridge Observer Decorator State Strategy Template Method Flyweight Pattern George Blankenship Visitor 2 The Elements of a Design Pattern • A pattern name • The problem that the pattern solves – Including conditions for the pattern to be applicable • The solution to the problem brought by the pattern – The elements (classes-objects) involved, their roles, responsibilities, relationships and collaborations – Not a particular concrete design or implementation • The consequences of applying the pattern – Time and space trade off – Language and implementation issues – Effects on flexibility, extensibility, portability Flyweight Pattern George Blankenship 3 George Blankenship 1 Object-Oriented Desgin Flyweight Pattern The Flyweight Pattern: The Problem Some applications benefit from using objects in their design but a naïve implementation is prohibitively expensive because of the large number of objects Column • use an object for each character in a text document editor Character h a l l o • use a layout object for each widget in a GUI Row Flyweight Pattern George Blankenship 4 Page Objects Flyweight Pattern George Blankenship 5 Page Classes Flyweight
    [Show full text]
  • Design Pattern Driven Development of Model Transformations
    DESIGN PATTERN DRIVEN DEVELOPMENT OF MODEL TRANSFORMATIONS by HUSEYIN ERGIN JEFF GRAY, COMMITTEE CHAIR JEFFREY CARVER RALF LAEMMEL RANDY SMITH EUGENE SYRIANI SUSAN VRBSKY A DISSERTATION Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science in the Graduate School of The University of Alabama TUSCALOOSA, ALABAMA 2017 Copyright Huseyin Ergin 2017 ALL RIGHTS RESERVED ABSTRACT Model-Driven Engineering (MDE) is considered a well-established software development ap- proach that uses abstraction to bridge the gap between the problem space and the software implementation. These abstractions are represented by models that make the validation of the real system easier. In MDE, many problems are solved using model transformation, which is a paradigm that manipulates high-level models to translate, evolve, or simulate them. However, the development of a model transformation for a specific problem is still a hard task. The main reason is the lack of a development process where transformations must be designed before implemented. Design patterns provide experiential reuse to soft- ware engineers when faced with recurring problems. In the literature, design patterns have been used to generate partially reusable software designs in order to help developers. There are many design patterns focused development methodologies proposed. However, most of them specialize in object-oriented design patterns. Given the various contexts in which de- sign patterns have been applied, model transformations may also benefit from a patterns approach. Although several studies have proposed design patterns for model transforma- tion, there is still no accepted common language to express them or a methodology that places design patterns at the heart of the development of model transformations.
    [Show full text]
  • Enabling White-Box Reuse in a Pure Composition Language
    Enabling White-Box Reuse in a Pure Composition Language Diplomarbeit der Philosophisch-naturwissenschaftlichen Fakultat¨ der Universitat¨ Bern vorgelegt von Andreas Schlapbach Dezember 2002 Leiter der Arbeit: Prof. Dr. O. Nierstrasz Nathanael Scharli¨ Institut fur¨ Informatik und angewandte Mathematik i Abstract Inheritance is a key concept of object-oriented programming languages, features such as conceptual modeling and reusability are largely accredited to it. While many useful com- ponents have been, and will be, developed in this paradigm, the form of white-box reuse offered by inheritance has a fundamental flaw: reusing components by inheritance requires an understanding of the internals of the components. We can not treat components of object-oriented languages as black-box entities, inheritance breaks encapsulation and in- troduces subtle dependencies between base and extending classes. Component-oriented programming addresses this problem by shifting away from program- ming towards software composition. We build applications by scripting components. In- stead of overriding the internals of a component, we focus on composing its interfaces only. This form of black-box reuse leads to a flexible and extendible architecture with reusable components. In this master's thesis we propose a migration strategy from class inheritance { a white- box form of reuse { to component composition as a black-box form of reuse. We present a language extension that gives us the power of inheritance combined with the ease of scripting. It enables us to reuse Java components using inheritance in JPiccola { a small, pure and general composition language implemented on the Java platform { at a high level of abstraction. Using the services provided by the language extension we can seamlessly generate interfaces and subclasses from JPiccola.
    [Show full text]
  • Design Patterns Chapter 3
    A Brief Introduction to Design Patterns Jerod Weinman Department of Computer Science Grinnell College [email protected] Contents 1 Introduction 2 2 Creational Design Patterns 4 2.1 Introduction ...................................... 4 2.2 Factory ........................................ 4 2.3 Abstract Factory .................................... 5 2.4 Singleton ....................................... 8 2.5 Builder ........................................ 8 3 Structural Design Patterns 10 3.1 Introduction ...................................... 10 3.2 Adapter Pattern .................................... 10 3.3 Façade ......................................... 11 3.4 Flyweight ....................................... 12 3.5 Proxy ......................................... 13 3.6 Decorator ....................................... 14 4 Behavioral Design Patterns 20 4.1 Introduction ...................................... 20 4.2 Chain of Responsibility ................................ 20 4.3 Observer ........................................ 20 4.4 Visitor ......................................... 22 4.5 State .......................................... 25 1 Chapter 1 Introduction As you have probably experienced by now, writing correct computer programs can sometimes be quite a challenge. Writing the programs is fairly easy, it can be the “correct” part that maybe is a bit hard. One of the prime culprits is the challenge in understanding a great number of complex interactions. We all have probably experienced the crash of some application program
    [Show full text]