DOCSLIB.ORG

Design Patterns from the Original [GOF] C++ Version with Some Regard to Java Implementation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Enrico Vicario - AA 13/14 SW Engineering Software Engineering - A.A. 13/14 Design Patterns From the original [GOF] c++ version with some regard to Java implementation Enrico Vicario Dipartimento di Ingegneria dell'Informazione Laboratorio Scienza e Tecnologia del Software Università di Firenze [email protected], www.dsi.unifi.it/~vicario 1/97 Enrico Vicario - AA 13/14 Design Patterns SW Engineering ° Design pattern: a reusable solution scheme for some recurrent problem ° A name, a problem, alternative solutions, known consequences, … ° Term first made explicit in Architecture by Christopher Alexander ° A Handbook of electronics schemes (e.g. amplifiers push-pull, totem-pole, …) ° ProducerConsumer or Monitor are also patterns in operating systems ° Patterns in OO Design ° Advanced use of OO programming schemes ° Substitutability and polymorphism, inheritance, composition, … ° Override, method look-up or dynamic binding and virtual methods, … ° Differently mapped to different languages 2/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° The problem ° (an object of type) Subject has a state variable whose value is necessary also to (objects of type) Observer_A and Observer_B ° (this might occur in the transition from specification to implementation, or in refactoring for separation of main concerns) ° Much about maintaining consistence across decoupling ° a naive solution ° (naive is a positive attribute, when beginning) ° Subject provides a public method that Observer invokes to get the value ° But, when shall the Observer unpdate its copy of the state? … might be before using it … but, intermediate states could be relevant as well (e.g. Computing interest on a banking current account) 3/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° one step ahead ° assign to Subject the responsibility of notifying Observers (inversion of responsibility) ° after any change of its state, Subject invokes notify() which in turn invokes update() on each Observer ° Yet, the Subject must be aware of all the types and instances of Observer 4/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° Some further steps ahead ° Move out from Subject the responsibility to register Observers: attach() and detach() to be used by the Observers, or by their creators (one more inversion of resposnibility) ° Decouple the inherent business of a Subject from being observable (using inheritance to reuse the methods for observability) ° Abstract Observers under a common interface for homogenous collection ° Call this Observer ° define a one to many dependency so that when an object changes state all its dependents are notified ° Also Known As: Publish & Subscribe (enterprise scale) 5/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° Dynamic registration of Observers on the Subject ° attach() and detach() invoked by the Observer or someone else ° Subject notifies to AbstractSubject (same object) through notify() ° notify() invokes update() on each registered Observer ° Each Observer may call-back on getState() to get the state (pull vs push mode) 6/97 Enrico Vicario - AA 13/14 The Observer pattern SW Engineering ° Amplification of interaction :-( ° In principle might even be unbounded (call-backs) ° Can be reduced by registering Observers on specific Topics, at the attach() ° usual in the enterprise scale publish&subscribe ° Pull vs puh mode ° Pull: the Subject notifies that a change happened, and the Observer calls-back, if needed, accordind to its policy ° Push: Notification from the Subject carries the state change some parameter to distinguish among multiple subjects ° A matter of: efficiency, robustness, coupling ° State consistency ° When the update() is performed, the state must be “stable”, but, some action might trigger multiple "atomic" state changes ° A change manager (Mediator pattern) may get responsibility of coordination 7/97 Enrico Vicario - AA 13/14 Design Patterns [GOF] SW Engineering ° A system of 23 Design Patterns ° [GOF95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, "Design Patterns, elements of reusable Object-Oriented software" ° In the next few slides: emphasis on how a pattern is described, not on the pattern itself 8/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : WHEN SW Engineering ° Intent ° Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. ° Also known as ° Publish & subscribe, Dependents, (Listener) ° Motivation: ° <a situation where the problem may occur> ° A common side-effect of partitioning is the need to maintain consistency between related objects, without making the classes tightly coupled, so as because that preserve reusability. ° A User Interface based on the Model View Controller ° Applicability ° When a change to one object requires changing others, and you don't know how many objects need to be changed. 9/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : HOW 1/3 SW Engineering ° Structure ° Described through a class diagram ° Close enough, c++ biased, but basically agnostic 10/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : HOW 2/3 SW Engineering ° Participants ° Subject: knows its observers; any number of Observer objects may observe a subject; provides an interface for attaching and detaching Observer objects. ° Observer: defines an updating interface for objects that should be notified of changes in a subject. ° ConcreteSubject: stores state of interest to ConcreteObserver objects; sends a notification to its observers when its state changes. ° ConcreteObserver: maintains a reference to a ConcreteSubject object; stores state that should stay consistent with the subject's; implements the Observer updating interface to keep its state consistent with the subject's. ° Collaborations ° ConcreteSubject notifies its observers whenever a change occurs ° After being informed of a change in the concrete subject, a ConcreteObserver object may query the subject for information. ° ConcreteObserver uses this information to reconcile its state with that of the subject. ° <Class, Responsibility, and Collaborations cards> ° 11/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : HOW 3/3 SW Engineering ° collaborations often documented through a sequence diagram 12/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : CONSEQUENCES SW Engineering ° Consequences ° <Good and bad news> ° As main consequences you can : vary subjects and observers independently; reuse subjects without reusing their observers, and vice versa; add observers without modifying the subject or other observers. ° Abstract coupling between Subject and Observer : Subject doesn't know the concrete class of any Observer ° Support for broadcast communication. ° Unexpected updates: since Observers do not know of each other, unexpected updates may occur :-( 13/97 Enrico Vicario - AA 13/14 description of a pattern (Observer) : IMPLEMENTATION SW Engineering ° Implementation ° Observing more than one subject : an Observer may depend on many Subjects; in this case, extend the update() interface to let the Observer know which Subject is sending the notification (a paremeter, or a self reference). ° Who triggers the update? Let state-setting methods of the Subject call notify(): simple, but possibly expensive with multiple consecutive changes; Or else, make clients responsible for calling notify() at the right time: is more efficient and flexible, but puts responsibility over (unknown) clients ° Dangling references to deleted Subjects ° Make sure Subject state is self-consistent before notification: unexpected notification may occur (e.g. a Subject subclass call inherited operations); document which Subject methods invoke notify() ° Update protocols: push/pull notification: ° Specifying modifications of interst explicitly: specify topics/aspects of interest to limit inteaction and update ° Sample Code ° <pieces of code, in c++> 14/97 Enrico Vicario - AA 13/14 description of a pattern (Observer): MORE SW Engineering ° Known uses ° Model view controller ° <often coming from a superior yet past world> ° Related Patterns ° Mediator: between Subjects and Observers, to encapuslate complex update ° Singleton: to ensure single instance of the Mediator 15/97 Enrico Vicario - AA 13/14 Impact of change from c+ to Java SW Engineering ° [GOF] Design Patterns refer to C++ ° but, patterns are by construction somehow language agnostic: no impact on WHEN, minor impact on STRUCTURE, some impact on IMPLEMENTATION ° What changes from c++ to java ? ° <intentionally incomplete> ° Method lookup vs dynamic binding and virtual methods ° single inheritance, interfaces, and abstract classes, ° Protected and package-private visibility ° Garbage collection ° Nested classes ° Concrete support from standard API ° <Often an opportunity more than problem to fix> ° Some references to work with ° J.W.Cooper, "The design patterns java companion" ° F.Guidi Polanco "GoF's Design Patterns in Java" ° J.Bloch, "Effective Java" ° … GOF, "Design Patterns, elements of reusable OO software" 16/97 Enrico Vicario - AA 13/14Patterns are often supported or applied by classes n standard APIs SW Engineering ° class java.util.Observable ° interface java.util.Observer 17/97 Enrico Vicario - AA 13/14 The Adapter pattern SW Engineering ° Intent ° Convert the interface of a class into another interface that clients expect ° Also Known as ° Wrapper ° Motivation ° an already
Recommended publications
  • Design Pattern Interview Questions

    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.
  • Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel

    Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel

    Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel Kelt Dockins [email protected] Design Patterns in PHP and Laravel Kelt Dockins Dolph, Arkansas USA ISBN-13 (pbk): 978-1-4842-2450-2 ISBN-13 (electronic): 978-1-4842-2451-9 DOI 10.1007/978-1-4842-2451-9 Library of Congress Control Number: 2016961807 Copyright © 2017 by Kelt Dockins This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
  • Enterprise Development with Flex

    Enterprise Development with Flex

    Enterprise Development with Flex Enterprise Development with Flex Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Enterprise Development with Flex by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Copyright © 2010 Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary E. Treseler Indexer: Ellen Troutman Development Editor: Linda Laflamme Cover Designer: Karen Montgomery Production Editor: Adam Zaremba Interior Designer: David Futato Copyeditor: Nancy Kotary Illustrator: Robert Romano Proofreader: Sada Preisch Printing History: March 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Enterprise Development with Flex, the image of red-crested wood-quails, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
  • Learning Javascript Design Patterns

    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
  • A Design Pattern Detection Tool for Code Reuse

    A Design Pattern Detection Tool for Code Reuse

    DP-CORE: A Design Pattern Detection Tool for Code Reuse Themistoklis Diamantopoulos, Antonis Noutsos and Andreas Symeonidis Electrical and Computer Engineering Dept., Aristotle University of Thessaloniki, Thessaloniki, Greece [email protected], [email protected], [email protected] Keywords: Design Pattern Detection, Static Code Analysis, Reverse Engineering, Code Reuse. Abstract: In order to maintain, extend or reuse software projects one has to primarily understand what a system does and how well it does it. And, while in some cases information on system functionality exists, information covering the non-functional aspects is usually unavailable. Thus, one has to infer such knowledge by extracting design patterns directly from the source code. Several tools have been developed to identify design patterns, however most of them are limited to compilable and in most cases executable code, they rely on complex representations, and do not offer the developer any control over the detected patterns. In this paper we present DP-CORE, a design pattern detection tool that defines a highly descriptive representation to detect known and define custom patterns. DP-CORE is flexible, identifying exact and approximate pattern versions even in non-compilable code. Our analysis indicates that DP-CORE provides an efficient alternative to existing design pattern detection tools. 1 INTRODUCTION ecutable. As a result, developers cannot exploit the source code of other systems without first resolving Developers need to understand existing projects in or- their dependencies and executing them correctly. Sec- der to maintain, extend, or reuse them. However, un- ondly, pattern representations in most tools are not in- derstanding usually comes down to understanding the tuitive, thus resulting in black box systems that do not source code of a project, which is inherently difficult, allow the developer any control over the detected pat- especially when the original software architecture and terns.
  • On the Interaction of Object-Oriented Design Patterns and Programming

    On the Interaction of Object-Oriented Design Patterns and Programming

    On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities.
  • Design Pattern Implementation in Java and Aspectj

    Design Pattern Implementation in Java and Aspectj

    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
  • A Design Pattern Generation Tool

    A Design Pattern Generation Tool

    Project Number: GFP 0801 A DESIGN PATTERN GEN ERATION TOOL A MAJOR QUALIFYING P ROJECT REPORT SUBMITTED TO THE FAC ULTY OF WORCESTER POLYTECHNIC INSTITUTE IN PARTIAL FULFILLME NT OF THE REQUIREMEN TS FOR THE DEGREE OF BACHELOR O F SCIENCE BY CAITLIN VANDYKE APRIL 23, 2009 APPROVED: PROFESSOR GARY POLLICE, ADVISOR 1 ABSTRACT This project determines the feasibility of a tool that, given code, can convert it into equivalent code (e.g. code that performs the same task) in the form of a specified design pattern. The goal is to produce an Eclipse plugin that performs this task with minimal input, such as special tags.. The final edition of this plugin will be released to the Eclipse community. ACKNOWLEGEMENTS This project was completed by Caitlin Vandyke with gratitude to Gary Pollice for his advice and assistance, as well as reference materials and troubleshooting. 2 TABLE OF CONTENTS Abstract ....................................................................................................................................................................................... 2 Acknowlegements ................................................................................................................................................................... 2 Table of Contents ..................................................................................................................................................................... 3 Table of Illustrations .............................................................................................................................................................
  • Additional Design Pattern Examples Design Patterns--Factory Method

    Additional Design Pattern Examples Design Patterns--Factory Method

    Additional Design Pattern Examples • Creational – Factory method – Abstract factory • Structural – Decorator – Adapter • Behavioral – Observer Design Patterns--Factory Method • Intent--Permit a class to be reuseable with arbitrary data types. Specifically, allow the class to be independent of the classes it instantiates – Define an interface for object creation. – Let subclasses decide which class to instantiate. • Motivation – Useful for development of frameworks 1 Factory Method--Continued • Consider a document-processing framework – High-level support for creating, opening, saving documents – Consistent method calls for these commands, regardless of document type (word-processor, spreadsheet, etc.) – Logic to implement these commands delegated to specific types of document objects. – May be some operations common to all document types. Factory Method--Continued Document Processing Example-General Framework: Document Application getTitle( ) * Edits 1 newDocument( ) newDocument( ) openDocument( ) openDocument( ) ... ... MyDocument Problem: How can an Application object newDocument( ) create instances of specific document classes openDocument( ) without being application-specific itself. ... 2 Factory Method--Continued Use of a document creation “factory”: Document Application getTitle( ) * Edits 1 newDocument( ) newDocument( ) openDocument( ) openDocument( ) ... ... 1 requestor * Requests-creation creator 1 <<interface>> MyDocument DocumentFactoryIF newDocument( ) createDocument(type:String):Document openDocument( ) ... DocumentFactory
  • Abstract Factory and Singleton Design Patterns to Create Decorator Pattern Objects in Web Application

    Abstract Factory and Singleton Design Patterns to Create Decorator Pattern Objects in Web Application

    International Journal of Advanced Information Technology (IJAIT) Vol. 1, No.5, October 2011 ABSTRACT FACTORY AND SINGLETON DESIGN PATTERNS TO CREATE DECORATOR PATTERN OBJECTS IN WEB APPLICATION Vijay K Kerji Department of Computer Science and Engineering, PDA College of Engineering,Gulbarga, India [email protected] ABSTRACT Software Design Patterns are reusable designs providing common solutions to the similar kind of problems in software development. Creational patterns are that category of design patterns which aid in how objects are created, composed and represented. They abstract the creation of objects from clients thus making the application more adaptable to future requirements changes. In this work, it has been proposed and implemented the creation of objects involved in Decorator Design Pattern. (Decorator Pattern Adds Additional responsibilities to the individual objects dynamically and transparently without affecting other objects). This enhanced the reusability of the application design, made application more adaptable to future requirement changes and eased the system maintenance. Proposed DMS (Development Management System) web application is implemented using .NET framework, ASP.NET and C#. KEYWORDS Design Patterns, Abstract Factory, Singleton, Decorator, Reusability, Web Application 1. INTRODUCTION Design Patterns refer to reusable or repeatable solutions that aim to solve similar design problems during development process. Various design patterns are available to support development process. Each pattern provides the main solution for particular problem. From developer’s perspectives, design patterns produce a more maintainable design. While from user’s perspectives, the solutions provided by design patterns will enhance the usability of web applications [1] [2]. Normally, developers use their own design for a given software requirement, which may be new each time they design for a similar requirement.
  • Java Design Patterns I

    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.............................................
  • Design Patterns Past and Future

    Design Patterns Past and Future

    Proceedings of Informing Science & IT Education Conference (InSITE) 2011 Design Patterns Past and Future Aleksandar Bulajic Metropolitan University, Belgrade, Serbia [email protected]; [email protected] Abstract A very important part of the software development process is service or component internal de- sign and implementation. Design Patterns (Gamma et al., 1995) provide list of the common pat- terns used in the object-oriented software design process. The primary goal of the Design Patterns is to reuse good practice in the design of new developed components or applications. Another important reason of using Design Patterns is improving common application design understand- ing and reducing communication overhead by reusing the same generic names for implemented solution. Patterns are designed to capture best practice in a specific domain. A pattern is supposed to present a problem and a solution that is supported by an example. It is always worth to listen to an expert advice, but keep in mind that common sense should decide about particular implemen- tation, even in case when are used already proven Design Patterns. Critical view and frequent and well designed testing would give an answer about design validity and a quality. Design Patterns are templates and cannot be blindly copied. Each design pattern records design idea and shall be adapted to particular implementation. Using time to research and analyze existing solutions is recommendation supported by large number of experts and authorities and fits very well in the pattern basic philosophy; reuse solution that you know has been successfully implemented in the past. Sections 2 and 3 are dedicated to the Design Patterns history and theory as well as literature sur- vey.