DOCSLIB.ORG

Creational Design Patterns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Creational Design Patterns COSC 3351 Software Design Design Patterns Creational Patterns Edgar Gabriel Spring 2008 Edgar Gabriel Object Oriented Software Design • Determine right granularity of objects • Define class interfaces and inheritance hierarchies • Establish key relationships • Design should be specific to solve a problem • …but general enough to be reusable • Experienced designer do not solve every problem from scratch – Reuse solutions that worked in the past – Leads to recurring patterns in many programs COSC 3351 – Software Design Edgar Gabriel 1 Design patterns • A design pattern is a way of reusing abstract knowledge about a problem and its solution – Patterns are devices that allow programs to share knowledge about their design • A pattern is a description of the problem and the essence of its solution – Documenting patterns is one way to reuse and share the information about how it is best to solve a specific design problem • A pattern should be sufficiently abstract to be reused in different settings • Patterns often rely on object characteristics such as inheritance and polymorphism COSC 3351 – Software Design Edgar Gabriel History of Design Patterns • Architect Christopher Alexander – A Pattern Language (1977) – A Timeless Way of Building (1979) • “Gang of four” • Erich Gamma • Richard Helm • Ralph Johnson • John Vlissides – Design Patterns: Elements of Reusable Object- Oriented Software (1995) • Many since • Conferences, symposia, books COSC 3351 – Software Design Edgar Gabriel 2 Pattern elements • Name – A meaningful pattern identifier • Problem description • Solution description – Not a concrete design but a template for a design solution that can be instantiated in different ways • Consequences – The results and trade-offs of applying the pattern COSC 3351 – Software Design Edgar Gabriel Abstraction Levels Patterns exist on different abstraction levels: • basic building blocks (algorithms and components), provided by language or by libraries • e.g. hash tables, linked lists, sort algorithms, math • e.g. inheritance and polymorphism, encapsulation • design patterns : general design problems in particular context concerning several classes • e.g.GOF-design patterns • architecture patterns : architecture decisions concerning the whole system (or subsystem) • Architectural styles discussed previously COSC 3351 – Software Design Edgar Gabriel 3 Classifying design patterns • Purpose: – Creational: concern the process of object creation – Structural: composition of classes or objects – Behavioral: characterize ways in which objects interact and distribute responsibility • Scope: – Class patterns: deal with relationships between classes and subclasses, i.e. inheritance • Static, compile time – Object patterns: can be changed at runtime, dynamically COSC 3351 – Software Design Edgar Gabriel Purpose Creational Structural Behavioral Scope Class Factory Method Adaptor(class) Interpreter Template Method Object Abstract Factory Adaptor(object) Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Singleton Decorator Mediator Façade Observer Flyweight State Proxy Strategy Visitor Memento COSC 3351 – Software Design Edgar Gabriel 4 Specifying Object Interfaces • An operation declared by an object specifies – Operation name – Objects taken as parameter – Return value -> operation signature • Set of signatures defines the interface of an object • An interface does not say anything about the implementation – Different objects having the same interface – Association of the request to an object at runtime known as dynamic binding COSC 3351 – Software Design Edgar Gabriel Specifying Object Interfaces • Class vs. Interface inheritance – Class inheritance defines an objects implementation in terms of another objects implementation • Mechanism for code reuse – Interface inheritance defines describes when an object can be used in place of another • Subtyping • In C++: inherit publicly from a class that has (pure) virtual functions COSC 3351 – Software Design Edgar Gabriel 5 Putting Reuse Mechanisms to Work • Class Inheritance – Reuse by subclassing – White box reuse: internals of parents class often visible to subclasses – Defined statically at compile time • Composition – Assembling objects in order to create more complex objects – Black-box reuse: no internal details of objects visible COSC 3351 – Software Design Edgar Gabriel Putting Reuse Mechanisms to Work (II) • Parameterized types – Often called generics or templates – Define a type without specifying the types it uses – Static, compile time procedure • Delegation: – Two objects involved in handling a request • A receiving object delegates the operation to the delegate • Instead of the subclass being a ‘superclass’ the subclass would have a ‘superclass’ object COSC 3351 – Software Design Edgar Gabriel 6 Delegation example class I { public: virtual void f() = 0; virtual void g() = 0; } class A : public13 I { public: void f() { cout << "A: doing f()" << endl; } void g() { cout << "A: doing g()" << endl; } } class C : public I { public: C() : i( new A() ) { } virtual ~C() { delete i; } void f() { i->f(); } void g() { i->g(); } } int main() { C* c = new C(); c->f(); c->g(); COSC 3351 – Software Design }Edgar Gabriel An example: a maze game <<interface>> MapSite + Enter() Room Wall Door Maze - RoomNo - isOpen + AddRoom() + Enter() + Enter() + Enter() +RoomNo() + SetSide() + GetSide() COSC 3351 – Software Design Edgar Gabriel 7 class MapSite { public: virtual void Enter() = 0; }; 15 class Room : public MapSite { public: Room (int RoomNo); MapSite * GetSide(Direction) const; void SetSide (Direction, MapSite*); virtual void Enter(); private: MapSite *_sides[4]; int _RoomNo; } class Wall : public MapSite { public: Wall(); } class Door: public MapSite { public: Door (Room *=0, Room*=0 ); virtual void Enter(); Room * OtherSideFrom (Room *); private: Room *_room1, *_room2; bool _isOpen; COSC 3351 – Software Design }Edgar Gabriel // This class represents a collection of rooms class Maze { public: Maze();16 void AddRoom (Romm *); Room* RoomNo(int) const; }; // The class MazeGame creates a Maze Maze * MazeGame:: CreateMaze { Maze* aMaze = new Maze; Room* r1 = new Room( 1 ); Room* r2 = new Room( 2 ); Door* theDoor = new Door( r1, r2); aMaze->addRoom( r1 ); aMaze->addRoom( r2 ); r1->setSide( North, new Wall ); r1->setSide( East, theDoor ); r1->setSide( South, new Wall ); r1->setSide( West, new Wall ); r2->setSide( North, new Wall ); r2->setSide( East, new Wall ); r2->setSide( South, new Wall ); r2->setSide( West, theDoor ); return aMaze; COSC 3351 – Software Design }Edgar Gabriel 8 Problem with previous code • Contains the explicit types of Room, Door etc. – Difficult to reuse the room layout described by CreateMaze for other type of Doors, Walls etc. class BombedMazeGame : public MazeGame { public: Maze* CreateMaze() { Maze* aMaze = new Maze; Room* r1 = new RoomWithABomb( 1 ); Room* r2 = new RoomWithABomb( 2 ); Door* theDoor = new Door( r1, r2); aMaze->addRoom( r1 ); aMaze->addRoom( r2 ); r1->setSide( North, new BombedWall); r1->setSide( East, theDoor ); … COSC 3351 – Software Design Edgar Gabriel Abstract Factory • Intent: Provide an interface for creating families of related or dependent objects without specifying their concrete classes • Applicability : Use the Abstract Factory Pattern when – A system should be independent of how its products are created, composed and represented – A system should be configured with one of multiple families of products – A family of related product objects is designed to be used together, and you need to enforce this constraint – You want to provide a class library of products, and you want to reveal just the interfaces, not their implementation COSC 3351 – Software Design Edgar Gabriel 9 Abstract Factory (II) class MazeFactory { public: MazeFactory() { virtual Maze* MakeMaze() const {return new Maze; } virtual Wall* MakeWall() const {return new Wall; } virtual Room* MakeRoom (int n) const { return new Room (n)); } virtual Door* MakeDoor(Room *r1, Room *r2) const { return new Door ( r1, r2 ); } } Maze *MazeGame::CreateMaze (MazeFactory& factory ) { Maze* aMaze = factory.MakeMaze(); Room* r1 = factory.MakeRoom(1); Room* r2 = factory.MakeRoom(2); Door* aDoor = factory.MakeDoor ( r1, r2); … r1->SetSide(North, factory.MakeWall() ); … COSC 3351 – Software Design Edgar Gabriel Abstract Factory (III) class EnchantedMazeFactory : public MazeFactory public: EnchantedMazeFactory(); virtual Room* MakeRoom(int n) const { return new EnchantedRoom (n ); } virtual Door *MakeDoor(Room* r1, Room* r2 ) const { return new EnchantedDoor( r1, r2); } … MazeGame game; EnchantedMazeFactory factory; game.CreateMaze(factory); … COSC 3351 – Software Design Edgar Gabriel 10 Abstract Factory (IV) AbstractFactory Client CreateProductA() AbstractProductA CreateProductB() ProductA2 ProductA1 AbstractProductB ConcreteFactory1 ConcreteFactory2 CreateProductA() ProductB2 ProductB1 CreateProductB() COSC 3351 – Software Design Edgar Gabriel Abstract Factory (V) • Participants : – Abstract Factory: declares an interfaces for operations that create abstract product objects – ConcreteFactory: implements the operations to create concrete product objects – AbstractProduct: declares an interface for a type of product object – ConcreteProduct: defines a product to be created by corresponding concrete factory; implements the AbstractProduct interface – Client: uses only interfaces declared by AbstractFactory and AbstractProduct COSC 3351 – Software Design Edgar Gabriel 11 AbstractFactory (VI)
Load more

Recommended publications
  • (GOF) Java Design Patterns Mock Exams
    Gang of Four (GOF) Java Design Patterns Mock Exams http://www.JavaChamp.com Open Certification Plattform Authors: N. Ibrahim, Y. Ibrahim Copyright (c) 2009-2010 Introducing JavaChamp.com Website JavaChamp.com is an Open Certification Platform. What does this mean? JavaChamp is the best place to learn, share, and certify your professional skills. We help you develop yourself in the field of computer science and programming Here are the most significant features offered by JavaChamp: Online Exams Start Online Certification Exams in SCJP, SCEA, EJB, JMS, JPA and more... Top quality mock exams for SCJP, SCEA, EJB, JMS, JPA. Start Express or topic-wise customized exam. * We offer you unlimited free mock exams * Exams cover subjects like SCJP, SCEA, EJB, JMS, JPA,.. * You can take as many exams as you want and at any time and for no charges * Each exam contains 20 multiple choice questions * You can save the exams taken in your exams history * Your exams history saves the exams you took, the scores you got, time took you to finish the exam, date of examination and also saves your answers to the questions for later revision * You can re-take the same exam to monitor your progress * Your exams history helps the system to offer you variant new questions every time you take a new exam, therefore we encourage you to register and maintain an exams history Network Find guidance through the maze, meet Study-Mates, Coaches or Trainees... Studying together is fun, productive and helps you in building your professional network and collecting leads Bookshelf JavaChamp Bookshelf full of PDF eBooks..
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • 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]
  • JAVA CONCURRENCY ONLINE TRAINING – Java2aspire
    JAVA CONCURRENCY, JAVA PROFILING, THREAD POOLING, JAVA 8 Features, MAVEN and DESIGN PATTERNS ONLINE TRAINING By K.Ramesh Curriculum THREAD POOLING Day 01: Executor Framework 20 min Day 01: Java Profiling 10 min Day 01: Executor 10 min Day 01: ExecutorService 10 min Day 01: Executors 15 min Day 02: ThreadPoolExecutor 20 min Day 02: BlockingQueue 10 min Day 02: Callable vs Runnable 15 min Day 02: Future 15 min JAVA CONCURRENCY Day 03: ConcurrentHashMap 30 min Day 03: Producer Consumer 30 min Day 04: CountDownLatch 20 min Day 04: CyclicBarrier 20 min Day 04: Deadlock Condition 20 min Day 05: Race Condition 30 min Day 05: Semaphore 30 min JAVA 8 FEATURES Day 06: Lambda Expressions 40 min Day 06: Functional Interfaces 10 min Day 06: Functional Programming 10 min Day 07: Method References 10 min Day 07: Default Methods 40 min Day 07: Optional 10 min Day 08: Stream API 1 hour MAVEN Day 09: Project Object Model (POM) 20 min Day 09: Project Description 10 min Day 09: Public Repository 10 min Day 09: Dependency Management 10 min Day 09: Build Configuration 10 min Day 10: Installation 15 min Day 10: Dependency Scope 15 min Day 10: Proprietary Dependencies 15 min Day 10: Project Inheritance 15 min Day 11: Maven life cycle 20 min Day 11: Maven Directory Structure 20 min Day 11: Archetypes 20 min Day 12: Applications 1 hour DESIGN PATTERNS Day 13: Factory Pattern 20 min Day 13: Abstract Factory Pattern 10 min Day 13: Single Pattern 20 min Day 13: Prototype Pattern 10 min Day 14: Composite Pattern 10 min Day 14: Facade Pattern 15 min Day 14: DAO
    [Show full text]
  • Design Patterns in Ocaml
    Design Patterns in OCaml Antonio Vicente [email protected] Earl Wagner [email protected] Abstract The GOF Design Patterns book is an important piece of any professional programmer's library. These patterns are generally considered to be an indication of good design and development practices. By giving an implementation of these patterns in OCaml we expected to better understand the importance of OCaml's advanced language features and provide other developers with an implementation of these familiar concepts in order to reduce the effort required to learn this language. As in the case of Smalltalk and Scheme+GLOS, OCaml's higher order features allows for simple elegant implementation of some of the patterns while others were much harder due to the OCaml's restrictive type system. 1 Contents 1 Background and Motivation 3 2 Results and Evaluation 3 3 Lessons Learned and Conclusions 4 4 Creational Patterns 5 4.1 Abstract Factory . 5 4.2 Builder . 6 4.3 Factory Method . 6 4.4 Prototype . 7 4.5 Singleton . 8 5 Structural Patterns 8 5.1 Adapter . 8 5.2 Bridge . 8 5.3 Composite . 8 5.4 Decorator . 9 5.5 Facade . 10 5.6 Flyweight . 10 5.7 Proxy . 10 6 Behavior Patterns 11 6.1 Chain of Responsibility . 11 6.2 Command . 12 6.3 Interpreter . 13 6.4 Iterator . 13 6.5 Mediator . 13 6.6 Memento . 13 6.7 Observer . 13 6.8 State . 14 6.9 Strategy . 15 6.10 Template Method . 15 6.11 Visitor . 15 7 References 18 2 1 Background and Motivation Throughout this course we have seen many examples of methodologies and tools that can be used to reduce the burden of working in a software project.
    [Show full text]
  • A Survey of Design Pattern Based Web Applications
    JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering ©JOT, 2009 Vol. 8, No. 2, March-April 2009 A Survey of Design Pattern Based Web Applications Sridaran R, Campus Head, ICFAI National College, Vellore-632 006 India. Padmavathi G, Professor and Head, Department of Computer Science, Avinashilingam University for Women, Coimbatore-641 043, India. Iyakutti K, Senior Professor, School of Physics, Madurai Kamaraj University, Madurai-625 019, India. Abstract Pattern-based web applications have become popular since they promote reusability and consistency. In few cases, patterns do not produce the desired effect because of lack of experience in applying them. This situation forces one to think of a suitable re- engineering solution for such applications. The objectives of the paper are three fold. It provides a survey of different pattern-based web applications that will be useful for the application designers. It highlights some of the web applications where patterns have been inappropriately handled. A few re-engineering initiatives for such cases are also analyzed. Key Words: Patterns, Web Applications, Re-engineering, Hypermedia, Semantic web, Partitioning. 1 INTRODUCTION Web application designers need to address many challenges during development in order to comply the quality of service requirements including speed, scalability and security. In recent years numerous non-web based applications have been re-written as web based because of the ever growing business needs. These migration activities are much more complicated and time consuming than a new software development. Most of these challenges are with data handling, organizing, or structuring of the web applications.
    [Show full text]
  • Course Title
    "Charting the Course ... ... to Your Success!" JavaScript Advanced Course Summary Description This course will review the basics of JavaScript and provide instruction on advanced topics such as advanced features of JavaScript functions, Object-Oriented programming in JavaScript (Inheritance, encapsulation) with prototypes, using closures, understanding JavaScript promises and advanced best practices. Objectives At the end of this course, students will be able to: Review Learn function expressions/function declarations/immediately executable functions Use JavaScript objects to implement Inheritance and encapsulation Understand JavaScript closures Learn JavaScript promises Discuss how to best use the advanced topics in this course in your JavaScript projects. Topics Basics Review Object-Oriented Programming Function Expressions Error Handling And Debugging Advanced Techniques Audience This course is intended for JavaScript programmers Prerequisites JavaScript introduction Duration Two days Due to the nature of this material, this document refers to numerous hardware and software products by their trade names. References to other companies and their products are for informational purposes only, and all trademarks are the properties of their respective companies. It is not the intent of ProTech Professional Technical Services, Inc. to use any of these names generically "Charting the Course ... ... to Your Success!" JavaScript Advanced Course Outline I. Basics Review IV. Error Handling And Debugging A. Browser Error Reporting II. Object-Oriented Programming B. Internet Explorer A. Understanding Objects C. Firefox B. Types of Properties D. Chrome C. Defining Multiple Properties E. Error Handling D. Reading Property Attributes F. The try-catch Statement E. Object Creation G. Throwing Errors F. The Factory Pattern H. The error Event G. The Constructor Pattern I.
    [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]
  • Java Design Patterns I
    Java Design Patterns i Java Design Patterns Java Design Patterns ii Contents 1 Introduction to Design Patterns 1 1.1 Introduction......................................................1 1.2 What are Design Patterns...............................................1 1.3 Why use them.....................................................2 1.4 How to select and use one...............................................2 1.5 Categorization of patterns...............................................3 1.5.1 Creational patterns..............................................3 1.5.2 Structural patterns..............................................3 1.5.3 Behavior patterns...............................................3 2 Adapter Design Pattern 5 2.1 Adapter Pattern....................................................5 2.2 An Adapter to rescue.................................................6 2.3 Solution to the problem................................................7 2.4 Class Adapter..................................................... 11 2.5 When to use Adapter Pattern............................................. 12 2.6 Download the Source Code.............................................. 12 3 Facade Design Pattern 13 3.1 Introduction...................................................... 13 3.2 What is the Facade Pattern.............................................. 13 3.3 Solution to the problem................................................ 14 3.4 Use of the Facade Pattern............................................... 16 3.5 Download the Source Code.............................................
    [Show full text]
  • Table of Contents
    Table of Contents ± -—T^jTp^om Object-Oriented to Functional Programming 5 Chajava- an introduction 5 java programming paradigms 6 CO imperative programming CD Real-life imperative example Object-oriented paradigm 7 Objects and classes 7 Encapsulation 7 Abstraction 8 Inheritance 8 Polymorphism 9 Declarative programming 10 Functional programming 11 Working with collections versus working with streams 11 An introduction to Unified Modeling Language 12 Class relations 14 Generalization 15 Realization 15 Dependency 16 Association 16 Aggregation 16 Composition 17 Design patterns and principles 17 Single responsibility principle 18 Open/closed principle 20 Liskov Substitution Principle 20 Interface Segregation Principle 22 Dependency inversion principle 23 Summary 24 Chapter 2: Creational Patterns 27 Singleton pattern 27 Synchronized singletons 29 Synchronized singleton with double-checked locking mechanism 30 Lock-free thread-safe singleton 30 tu * y and lazy loacling 31 i he factory pattern 31 Simple factory pattern 32 Table of Contents Static factory 33 Simple factory with class registration using reflection 34 Simple factory with class registration using Product.newlnstance 35 Factory method pattern 36 Anonymous concrete factory 38 Abstract factory 38 Simple factory versus factory method versus abstract factory 40 Builder pattern 40 Car builder example 41 Simplified builder pattern 43 Anonymous builders with method chaining 44 Prototype pattern 45 Shallow clone versus deep clone Object pool pattern Summary аэоэсБ Chapter 3: Behavioral Patterns
    [Show full text]
  • Object-Oriented Design Patterns
    Object-Oriented Design Patterns David Janzen EECS 816 Object-Oriented Software Development University of Kansas Outline • Introduction – Design Patterns Overview – Strategy as an Early Example – Motivation for Creating and Using Design Patterns – History of Design Patterns • Gang of Four (GoF) Patterns – Creational Patterns – Structural Patterns – Behavioral Patterns Copyright © 2006 by David S. 2 Janzen. All rights reserved. What are Design Patterns? • In its simplest form, a pattern is a solution to a recurring problem in a given context • Patterns are not created, but discovered or identified • Some patterns will be familiar? – If you’ve been designing and programming for long, you’ve probably seen some of the patterns we will discuss – If you use Java Foundation Classes (Swing), Copyright © 2006 by David S. 3 you have certaJiannzleyn. Aulls rieghdts rsesoervmed.e design patterns Design Patterns Definition1 • Each pattern is a three-part rule, which expresses a relation between – a certain context, – a certain system of forces which occurs repeatedly in that context, and – a certain software configuration which allows these forces to resolve themselves 1. Dick Gabriel, http://hillside.net/patterns/definition.html Copyright © 2006 by David S. 4 Janzen. All rights reserved. A Good Pattern1 • Solves a problem: – Patterns capture solutions, not just abstract principles or strategies. • Is a proven concept: – Patterns capture solutions with a track record, not theories or speculation 1. James O. Coplien, http://hillside.net/patterns/definition.html Copyright © 2006 by David S. 5 Janzen. All rights reserved. A Good Pattern • The solution isn't obvious: – Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles.
    [Show full text]
  • Non-Software Examples of Software Design Patterns Автор: Michael Duell
    Non-Software Examples of Software Design Patterns Автор: Michael Duell. Хорошая, хоть и старая (97 год) статья в которой приведены примеры применения паттернов в вещах, которые не имеют отношения к разработке. Такой подход отлично иллюстрирует паттерны и делает их более доступными для понимания. Например отлично показан паттерн Фасад: интерфейсы офисных устройств можно сильно упростить с помощью секретарши. Или например паттерн Бридж, который показан на примере выключателя которым можно управлять лампочкой, вентилятором или любым другим прибором. Non-Software Examples of Software Design Patterns by Michael Duell Abstract Software design patterns have roots in the architectural patterns of Christopher Alexander, and in the object movement. According to Alexander, patterns repeat themselves, since they are a generic solution to a given system of forces. The object movement looks to the real world for insights into modeling software relationships. With these dual roots, it seems reasonable that software design patterns should be repeated in real world objects. This paper presents a real world, non software instance of each design pattern from the book, Design Patterns - Elements of Reusable Object-Oriented Software [13]. The paper also discusses the implications of non-software examples on the communicative power of a pattern language, and on design pattern training. 1. Introduction Within the software industry, a growing community of patterns proponents exists. The roots of the patterns movement are found in the writings of architect Christopher Alexander, who describes a pattern as a generic solution to a given system of forces in the world [1]. Alexander's patterns can be observed in everyday structures. Each pattern in A Pattern Language[2] includes a picture of an archetypal example of the pattern.
    [Show full text]