DOCSLIB.ORG

Concurrency by Modularity: Design Patterns, a Case in Point Hridesh Rajan [email protected]

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Concurrency by Modularity: Design Patterns, a Case in Point Hridesh Rajan Hridesh@Iastate.Edu Computer Science Conference Presentations, Computer Science Posters and Proceedings 10-10-2010 Concurrency by modularity: design patterns, a case in point Hridesh Rajan [email protected] Steven M. Kautz Iowa State University, [email protected] Wayne Rowcliffe Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_conf Part of the Software Engineering Commons Recommended Citation Rajan, Hridesh; Kautz, Steven M.; and Rowcliffe, Wayne, "Concurrency by modularity: design patterns, a case in point" (2010). Computer Science Conference Presentations, Posters and Proceedings. 39. http://lib.dr.iastate.edu/cs_conf/39 This Conference Proceeding is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Conference Presentations, Posters and Proceedings by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Concurrency by modularity: design patterns, a case in point Abstract General purpose object-oriented programs typically aren't embarrassingly parallel. For these applications, finding enough concurrency remains a challenge in program design. To address this challenge, in the Panini project we are looking at reconciling concurrent program design goals with modular program design goals. The ainm idea is that if programmers improve the modularity of their programs they should get concurrency for free. In this work we describe one of our directions to reconcile these two goals by enhancing Gang-of- Four (GOF) object-oriented design patterns. GOF patterns are commonly used to improve the modularity of object-oriented software. These patterns describe strategies to decouple components in design space and specify how these components should interact. Our hypothesis is that if these patterns are enhanced to also decouple components in execution space applying them will concomitantly improve the design and potentially available concurrency in software systems. To evaluate our hypothesis we have studied all 23 GOF patterns. For 18 patterns out of 23, our hypothesis has held true. Another interesting preliminary result reported here is that for 17 out of these 18 studied patterns, concurrency and synchronization concerns were completely encapsulated in our concurrent design pattern framework. Disciplines Computer Sciences | Software Engineering Comments This article is published as Rajan, Hridesh, Steven M. Kautz, and Wayne Rowcliffe. "Concurrency by modularity: Design patterns, a case in point." In ACM Sigplan Notices, vol. 45, no. 10, pp. 790-805. ACM, 2010. doi: 10.1145/1932682.1869523. Posted with permission. Rights © ACM, 2010. This is the author's version of the work. It is posted here by permission of ACM for your personal use. Not for redistribution. The definitive version was published in ACM Sigplan Notices, vol. 45, no. 10, pp. 790-805. ACM, 2010. https://doi.org/10.1145/1932682.1869523 This conference proceeding is available at Iowa State University Digital Repository: http://lib.dr.iastate.edu/cs_conf/39 Concurrency by Modularity: Design Patterns, a Case in Point Hridesh Rajan Steven M. Kautz Wayne Rowcliffe Dept. of Computer Science Iowa State University 226 Atanasoff Hall, Ames, IA, 50010, USA {hridesh,smkautz,wrowclif}@iastate.edu Abstract Keywords Modularity, concurrency, ease of program de- General purpose object-oriented programs typically aren’t sign, design patterns, synergistic decoupling embarrassingly parallel. For these applications, finding enough concurrency remains a challenge in program de- 1. Introduction sign. To address this challenge, in the Pa¯nini¯ project we A direct result of recent trends in hardware design towards are looking at reconciling concurrent program design goals multicore CPUs with hundreds of cores is that the need with modular program design goals. The main idea is that for scalability of today’s general-purpose programs can no if programmers improve the modularity of their programs longer be simply fulfilled by faster CPUs. Rather, these pro- they should get concurrency for free. In this work we de- grams must now be designed to take advantage of the inher- scribe one of our directions to reconcile these two goals by ent concurrency in the underlying computational model. enhancing Gang-of-Four (GOF) object-oriented design pat- terns. GOF patterns are commonly used to improve the mod- 1.1 The Problems and their Importance ularity of object-oriented software. These patterns describe Scalability of general-purpose programs faces two major strategies to decouple components in design space and spec- hurdles. A first and well-known hurdle is that writing cor- ify how these components should interact. Our hypothesis is rect and efficient concurrent programs has remained a chal- that if these patterns are enhanced to also decouple compo- lenge [2, 22, 24, 32]. A second and less explored hurdle is nents in execution space applying them will concomitantly that unlike in scientific applications, in general-purpose pro- improve the design and potentially available concurrency in grams potential concurrency isn’t always obvious. software systems. To evaluate our hypothesis we have stud- We believe that both these hurdles are in part due to a ied all 23 GOF patterns. For 18 patterns out of 23, our hy- significant shortcoming of the current concurrent language pothesis has held true. Another interesting preliminary result features or perhaps the design discipline that they promote. reported here is that for 17 out of these 18 studied patterns, These features treat modular program design and concurrent concurrency and synchronization concerns were completely program design as two separate and orthogonal goals. As a encapsulated in our concurrent design pattern framework. result, concurrent program design as a goal is often tackled at a level of abstraction lower than modular program design. Categories and Subject Descriptors D.2.10 [Software Synchronization defects arise when developers work at low Engineering]: Design; D.1.5 [Programming Techniques]: abstraction levels and are not aware of the behavior at a Object-Oriented Programming; D.2.2 [Design Tools and higher level of abstraction [23]. This unawareness also limits Techniques]: Modules and interfaces, Object-oriented design potentially available concurrency in resulting programs. methods; D.2.3 [Coding Tools and Techniques]: Object- To illustrate consider a picture viewer. The overall re- Oriented Programming; D.3.3 [Programming Languages]: quirement for this program is to display the input picture Language Constructs and Features raw, hereafter referred to as the display concern. To enhance General Terms Design, Human Factors, Languages the appearance of pictures this program is also required to apply such transformations as red-eye reduction, sharpening, etc, to raw pictures, henceforth referred to as the processing concern. The listing in Figure 1 shows snippets from a sim- Permission to make digital or hard copies of all or part of this work for personal or ple implementation of this picture viewer. classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation This listing shows a GUI-related class Display that on the first page. To copy otherwise, to republish, to post on servers or to redistribute is responsible for drawing borders, captions and displaying to lists, requires prior specific permission and/or a fee. Onward! 2010, October 17–21, 2010, Reno/Tahoe, Nevada, USA. pictures. The key method of the picture viewer is show, Copyright c 2010 ACM 978-1-4503-0236-4/10/10. $5.00. which given a raw picture processes it, draws a border and The class Processor now implements the processing 1 class Display { 2 Picture pic = null; concern using the Template Method design pattern [12]. 3 void show(Picture raw) { It provides a new template method process for its 4 Picture tmp = crop(raw); 5 tmp = sharpen(raw, tmp); client [12]. This allows independent evolution of var- 6 pic = redeye(raw, tmp); ious parts of the processing concern’s implementation, 7 displayBorders(); 8 displayCaption(); e.g. a new algorithm for red eye reduction could be 9 displayPicture(pic); added without extensively modifying the clients. Concrete 10 } 11 Picture redeye(Picture raw, Picture pic){ processing algorithms are implemented in the subclass 12 //Identify eyes in raw, make a copy of pic, BasicProcessor. The class Display creates and uses 13 //replace eye areas in copy with a gradient of blue. 14 return copy; } an instance of BasicProcessor on lines 4 and 5 respec- 15 Picture sharpen(Picture raw, Picture pic){ tively but remains independent of its implementation. 16 //Identify areas to sharpen in raw, make a copy 17 //of pic, increases contrast of selected areas in copy. 18 return copy; } 1.1.2 Improving Concurrency of Picture Viewer 19 Picture crop(Picture raw){ 20 // Find focus area, make a copy of raw, crop copy. On another day we may want to enhance the responsiveness 21 return copy; } of the picture viewer. An approach to do that could be to 22 //Elided code for displaying border, caption, and pic. 23 } render borders, captions, etc, concurrently with picture pro- cessing, which may take a long time to finish. This would Figure 1: A Picture Viewer and its two Tangled Concerns prevent such common nuisances as the “frozen user inter- face”. Starting
Load more

Recommended publications
  • Acceptor-Connector an Object Creational Pattern for Connecting and Initializing Communication Services
    Acceptor-Connector An Object Creational Pattern for Connecting and Initializing Communication Services Douglas C. Schmidt [email protected] Department of Computer Science Washington University St. Louis, MO 63130, USA An earlier version of this paper appeared in a chapter in TRACKING the book Pattern Languages of Program Design 3, edited SATELLITES STATION by Robert Martin, Frank Buschmann, and Dirke Riehle pub- PEERS lished by Addison-Wesley, 1997. 1Intent STATUS INFO The Acceptor-Connector design pattern decouples connec- WIDE AREA NETWORK tion establishment and service initialization in a distributed COMMANDS BULK DATA system from the processing performed once a service is ini- TRANSFER tialized. This decoupling is achieved with three compo- nents: acceptors, connectors,andservice handlers. A con- GATEWAY nector actively establishes a connection with a remote ac- ceptor component and initializes a service handler to pro- cess data exchanged on the connection. Likewise, an ac- LOCAL AREA NETWORK ceptor passively waits for connection requests from remote GROUND connectors, establishing a connection upon arrival of such a STATION PEERS request, and initializing a service handler to process data ex- changed on the connection. The initialized service handlers Figure 1: The Physical Architecture of a Connection- then perform application-specific processing and communi- oriented Application-level Gateway cate via the connection established by the connector and ac- ceptor components. The Gateway transmits data between its Peers using the connection-oriented TCP/IP protocol [1]. In our exam- 2 Example ple network configuration, each service is bound to a con- nection endpoint designated by an IP host address and a TCP To illustrate the Acceptor-Connector pattern, consider the port number.
    [Show full text]
  • Ece351 Lab Manual
    DEREK RAYSIDE & ECE351 STAFF ECE351 LAB MANUAL UNIVERSITYOFWATERLOO 2 derek rayside & ece351 staff Copyright © 2014 Derek Rayside & ECE351 Staff Compiled March 6, 2014 acknowledgements: • Prof Paul Ward suggested that we look into something with vhdl to have synergy with ece327. • Prof Mark Aagaard, as the ece327 instructor, consulted throughout the development of this material. • Prof Patrick Lam generously shared his material from the last offering of ece251. • Zhengfang (Alex) Duanmu & Lingyun (Luke) Li [1b Elec] wrote solutions to most labs in txl. • Jiantong (David) Gao & Rui (Ray) Kong [3b Comp] wrote solutions to the vhdl labs in antlr. • Aman Muthrej and Atulan Zaman [3a Comp] wrote solutions to the vhdl labs in Parboiled. • TA’s Jon Eyolfson, Vajih Montaghami, Alireza Mortezaei, Wenzhu Man, and Mohammed Hassan. • TA Wallace Wu developed the vhdl labs. • High school students Brian Engio and Tianyu Guo drew a number of diagrams for this manual, wrote Javadoc comments for the code, and provided helpful comments on the manual. Licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) version 2.5 or greater. http://creativecommons.org/licenses/by-sa/2.5/ca/ http://creativecommons.org/licenses/by-sa/3.0/ Contents 0 Overview 9 Compiler Concepts: call stack, heap 0.1 How the Labs Fit Together . 9 Programming Concepts: version control, push, pull, merge, SSH keys, IDE, 0.2 Learning Progressions . 11 debugger, objects, pointers 0.3 How this project compares to CS241, the text book, etc. 13 0.4 Student work load . 14 0.5 How this course compares to MIT 6.035 .......... 15 0.6 Where do I learn more? .
    [Show full text]
  • One-Slide Summary Lecture Outline
    Using Design Patterns #1 One-Slide Summary • Design patterns are solutions to recurring OOP design problems. There are patterns for constructing objects, structuring data, and object behavior . • Since this is PL, we’ll examine how language features like (multiple) inheritance and dynamic dispatch relate to design patterns. #2 Lecture Outline • Design Patterns • Iterator • Observer • Singleton • Mediator #3 1 What is a design pattern? • A solution for a recurring problem in a large object-oriented programming system – Based on Erich Gamma’s Ph.D. thesis, as presented in the “gang of four” book • “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” – Charles Alexander #4 Types of design patterns • Design patterns can be (roughly) grouped into three categories: • Creational patterns – Constructing objects • Structural patterns – Controlling the structure of a class, e.g. affecting the API or the data structure layout • Behavioral patterns – Deal with how the object behaves #5 Iterator design pattern • Often you may have to move through a collection – Tree (splay, AVL, binary, red-black, etc.), linked list, array, hash table, dictionary, etc. • Easy for arrays and vectors • But hard for more complicated data structures – Hash table, dictionary, etc. • The code doing the iteration should not have to know the details of the data structure
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Object-Oriented Analysis, Design and Implementation
    Undergraduate Topics in Computer Science Brahma Dathan Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition Undergraduate Topics in Computer Science Undergraduate Topics in Computer Science (UTiCS) delivers high-quality instruc- tional content for undergraduates studying in all areas of computing and information science. From core foundational and theoretical material to final-year topics and applications, UTiCS books take a fresh, concise, and modern approach and are ideal for self-study or for a one- or two-semester course. The texts are all authored by established experts in their fields, reviewed by an international advisory board, and contain numerous examples and problems. Many include fully worked solutions. More information about this series at http://www.springer.com/series/7592 Brahma Dathan • Sarnath Ramnath Object-Oriented Analysis, Design and Implementation An Integrated Approach Second Edition 123 Brahma Dathan Sarnath Ramnath Department of Information and Computer Department of Computer Science Science and Information Technology Metropolitan State University St. Cloud State University St. Paul, MN St. Cloud, MN USA USA Series editor Ian Mackie Advisory Board Samson Abramsky, University of Oxford, Oxford, UK Karin Breitman, Pontifical Catholic University of Rio de Janeiro, Rio de Janeiro, Brazil Chris Hankin, Imperial College London, London, UK Dexter Kozen, Cornell University, Ithaca, USA Andrew Pitts, University of Cambridge, Cambridge, UK Hanne Riis Nielson, Technical University of Denmark, Kongens Lyngby, Denmark Steven Skiena, Stony Brook University, Stony Brook, USA Iain Stewart, University of Durham, Durham, UK A co-publication with the Universities Press (India) Private Ltd., licensed for sale in all countries outside of India, Pakistan, Bhutan, Bangladesh, Sri Lanka, Nepal, The Maldives, Middle East, Malaysia, Indonesia and Singapore.
    [Show full text]
  • 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]
  • Design Patterns Design Patterns
    Design Patterns CSC207 – Software Design Design Patterns • Design pattern: – A general description of the solution to a well- established problem using an arrangement of classes and objects. • Patterns describe the shape of code rather than the details. – There are lots of them in CSC 301 and 302. Loop patterns from first year • Loop pattern: – A general description of an algorithm for processing items in a collection. • All of you (hopefully) have some loop patterns in your heads. • You don’t really need to think about these any more; you just use them, and you should be able to discuss them with your fellow students. • Some first-year patterns: – Process List – Counted Loop – Accumulator – Sentinel Process list pattern • Purpose: to process every item in a collection where you don’t care about order or context; you don’t need to remember previous items. • Outline: • Example: • Other example: darken every pixel in a picture Counted loop pattern • Purpose: to process a range of indices in a collection. • Outline: • Example: • Other example: print indices of even-length string Accumulator pattern • Purpose: to accumulate information about items in a collection. • Outline: • Example: • Other examples: sum, min, accumulate a list of items meeting a particular criterion. Sentinel pattern • Purpose: to remove a condition in a loop guard. • Outline: • Example: Sentinel pattern, continued • Here is the code that Sentinal replaces; note that i != list.size() is evaluated every time through the loop, even though it is false only once. Design Pattern
    [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 (Part 3)
    Design patterns (part 3) CSE 331 University of Washington Michael Ernst Outline Introduction to design patterns Creational patterns (constructing objects) Structural patterns (controlling heap layout) ⇒Behavioral patterns (affecting object semantics) Composite pattern Composite permits a client to manipulate either an atomic unit or a collection of units in the same way Good for dealing with part-whole relationships Composite example: Bicycle • Bicycle – Wheel • Skewer • Hub • Spokes • Nipples • Rim • Tape • Tube • Tire – Frame – Drivetrain – ... Methods on components class BicycleComponent { int weight (); float cost (); } class Skewer extends BicycleComponent { float price ; float cost () { return price; } } class Wheel extends BicycleComponent { float assemblyCost ; Skewer skewer ; Hub hub ; ... float cost () { return assemblyCost + skewer.cost() + hub.cost() + ...; } } Composite example: Libraries Library Section (for a given genre) Shelf Volume Page Column Word Letter interface Text { String getText (); } class Page implements Text { String getText () { ... return the concatenation of the column texts ... } } Traversing composites Goal: perform operations on all parts of a composite Representing Java code x = foo * b + c / d; = x + * / foo b c d Abstract syntax tree (AST) for Java code class PlusOp extends Expression { // + operation Expression leftExp ; Expression rightExp ; } class VarRef extends Expression { // variable reference String varname ; } class EqualOp extends Expression { // equality test a==b; Expression lvalue ; //
    [Show full text]
  • Automatic Generation of Truffle-Based Interpreters for Domain
    Automatic generation of Truffle-based interpreters for Domain-Specific Languages Manuel Leduc, Gwendal Jouneaux, Thomas Degueule, Gurvan Le Guernic, Olivier Barais, Benoit Combemale To cite this version: Manuel Leduc, Gwendal Jouneaux, Thomas Degueule, Gurvan Le Guernic, Olivier Barais, et al.. Automatic generation of Truffle-based interpreters for Domain-Specific Languages. The Journal of Object Technology, Chair of Software Engineering, 2020, 19 (2), pp.1-21. 10.5381/jot.2020.19.2.a1. hal-02395867v2 HAL Id: hal-02395867 https://hal.inria.fr/hal-02395867v2 Submitted on 21 Feb 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Journal of Object Technology Published by AITO — Association Internationale pour les Technologies Objets http://www.jot.fm/ Automatic generation of Truffle-based interpreters for Domain-Specific Languages Manuel Leduca Gwendal Jouneauxa Thomas Degueuleb Gurvan Le Guernicc Olivier Baraisa Benoit Combemalead a. Univ. Rennes, Inria, CNRS, IRISA, France b. Univ. Bordeaux, Bordeaux INP, CNRS, LaBRI, UMR5800, F-33400 Talence, France c. DGA MI, Bruz, France d. Univ. Toulouse, IRIT, France Abstract Numerous language workbenches have been proposed over the past decade to ease the definition of Domain-Specific Languages (DSLs).
    [Show full text]
  • Singleton ● Iterator
    CSC207 Week 6 Larry Zhang 1 Logistics ● Midterm: next Friday (October 27), 5:10 PM - 7:00 PM ● 110 minutes ● No aid ● Room: TBA (Note it’s not the lecture room) ● Past tests posted on the course website: http://axiom.utm.utoronto.ca/~207/17f/tests.shtml ● Arnold will send emails with more info. 2 Design Patterns 3 /r/LifeProTips 4 Design Patterns Design patterns are like “LifeProTips” for software design. ● Effective use of the OO Paradigm. ● Using the patterns results in flexible, malleable, maintainable code. ● It usually allows plug and play additions to existing code. ● It gives developers a vocabulary to talk about recurring class organizations. 5 Design Patterns for Today ● Observer ● Singleton ● Iterator 6 The Observer Pattern 7 Goals ● When certain objects need to be informed about the changes occurred in other objects. ● One object changes state, all its dependents are notified and updated automatically. ● Programmer only need to worry about how the observer changes if the observables changes, and connecting the observers and observables. ● Real-life example: setting up Pre-Authorized Bill Payment 8 General Implementation 9 Java Implementation 10 DEMO #1 Implement Our Own Observer/Observable observer/Observable.java observer/Observer.java 11 DEMO #2 Use Our Observer/Observable observer/LightBulb.java observer/LightBulbObserver.java observer/LightBulbObservable.java observer/LightBulbMain.java 12 Advanced Issues in Observer Pattern Push and Pull communication methods ● Push model: the Observable send all information about the change
    [Show full text]
  • Creational Patterns
    9. Creational Pattern Venkat Subramaniam CDP-1 Creational Patterns • Abstracts instantiation process • Makes system independent of how its objects are œ created œ composed œ represented • Encapsulates knowledge about which concrete classes the system uses • Hides how instances of these classes are created and put together Venkat Subramaniam CDP-2 Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes Venkat Subramaniam CDP-3 Example that would benefit from Abstract Factory ComputerModelA MemoryType A CPUTypeA ModemTypeA BuildComputer(ComputerModelA& comp) { comp.Add(new MemoryTypeA); comp.Add(new CPUTypeA); comp.Add(new ModemTypeA); } What if I want to build a Computer of Model B with Model B Memory,CPU and Modem? Venkat Subramaniam CDP-4 Using Abstract Factory ComputerFactory Client Computer createComputer() createMemory() createCPU() Computer Computer createModem() ModelA ModelB Memory CompFactoryB CompFactoryA createComputer() createComputer() Memory Memory createMemory() createMemory() ModelA ModelB createCPU() createCPU() createModem() createModem() Venkat Subramaniam CDP-5 Using Abstract Factory... BuildComputer(Computer& comp, ComputerFactory& compFactory) { comp.Add(compFactory.createMemory()) ; comp.Add(compFactory.createCPU()); comp.Add(compFactory.createModem()); } Venkat Subramaniam CDP-6 .hen to use Abstract Factory? • Use Abstract Factory when: œ system should be independent of how its products are created, composed and represented œ system should
    [Show full text]