DOCSLIB.ORG

An Introduction to Design Patterns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Introduction to Design Patterns An Introduction to Design Patterns Fabrizio Maria Maggi Institute of Computer Science (The java code and the material is taken from: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm) Software Development MethodologyDomain Classes; Application Classes (e.g., Patterns); Attributes; Relations; Operations Domain (Class) Application (Class) Model Interaction Model Modelling Code 1 Systems modelling – Fabrizio Maria Maggi Application (Class) Model 2 Systems modelling – Fabrizio Maria Maggi Application (Class) Model 3 Systems modelling – Fabrizio Maria Maggi Application (Class) Model 4 Systems modelling – Fabrizio Maria Maggi Application (Class) Model 5 Systems modelling – Fabrizio Maria Maggi What is Gang of Four (GOF) Gamma, Helm, Johnson, Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software Addison-Wesley 1994 Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides initiated the concept of Design Pattern in Software development These authors are collectively known as Gang of Four (GOF) . 6 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 Learning these patterns helps unexperienced developers to learn software design in an easy and faster way 7 Categories of Design Patterns 8 Categories of Design Patterns 9 Factory This type of design pattern comes under creational pattern In Factory pattern, we create object without exposing the creation logic to the client and refer to newly created object using a common interface 10 Systems modelling – Fabrizio Maria Maggi Factory 11 Systems modelling – Fabrizio Maria Maggi Factory 12 Systems modelling – Fabrizio Maria Maggi Factory 13 Systems modelling – Fabrizio Maria Maggi Factory 14 Systems modelling – Fabrizio Maria Maggi Abstract Factory Abstract Factory patterns work around a super-factory which creates other factories. This factory is also called as factory of factories This type of design pattern comes under creational pattern In Abstract Factory pattern an interface is responsible for creating a factory of related objects without explicitly specifying their classes. Each generated factory can give the objects as per the Factory pattern 15 Systems modelling – Fabrizio Maria Maggi Abstract Factory 16 Systems modelling – Fabrizio Maria Maggi Abstract Factory 17 Systems modelling – Fabrizio Maria Maggi Abstract Factory 18 Systems modelling – Fabrizio Maria Maggi Abstract Factory 19 Systems modelling – Fabrizio Maria Maggi Abstract Factory 20 Systems modelling – Fabrizio Maria Maggi Abstract Factory 21 Systems modelling – Fabrizio Maria Maggi Abstract Factory 22 Systems modelling – Fabrizio Maria Maggi Abstract Factory 23 Systems modelling – Fabrizio Maria Maggi Abstract Factory 24 Systems modelling – Fabrizio Maria Maggi Abstract Factory 25 Singleton Singleton pattern is one of the simplest design patterns in Java This type of design pattern comes under creational pattern This pattern involves a single class which is responsible to create an object while making sure that only single object gets created. This class provides a way to access its only object which can be accessed directly without need to instantiate the object of the class 26 Systems modelling – Fabrizio Maria Maggi Singleton 27 Systems modelling – Fabrizio Maria Maggi Singleton 28 Systems modelling – Fabrizio Maria Maggi Builder Builder pattern builds a complex object using simple objects and using a step by step approach This type of design pattern comes under creational pattern A Builder class builds the final object step by step. This builder is independent of other objects 29 Systems modelling – Fabrizio Maria Maggi Builder 30 Systems modelling – Fabrizio Maria Maggi Builder 31 Systems modelling – Fabrizio Maria Maggi Builder 32 Systems modelling – Fabrizio Maria Maggi Builder 33 Systems modelling – Fabrizio Maria Maggi Builder 34 Systems modelling – Fabrizio Maria Maggi Builder 35 Systems modelling – Fabrizio Maria Maggi Builder 36 Systems modelling – Fabrizio Maria Maggi Builder 37 Systems modelling – Fabrizio Maria Maggi Categories of Design Patterns 38 Adapter Adapter pattern works as a bridge between two incompatible interfaces This type of design pattern comes under structural pattern as this pattern combines the capability of two independent interfaces This pattern involves a single class which is responsible to join functionalities of independent or incompatible interfaces 39 Systems modelling – Fabrizio Maria Maggi Adapter 40 Systems modelling – Fabrizio Maria Maggi Adapter 41 Systems modelling – Fabrizio Maria Maggi Adapter 42 Systems modelling – Fabrizio Maria Maggi Adapter 43 Systems modelling – Fabrizio Maria Maggi Adapter 44 Systems modelling – Fabrizio Maria Maggi Filter Filter pattern or Criteria pattern is a design pattern that enables developers to filter a set of objects using different criteria and chaining them in a decoupled way through logical operations This type of design pattern comes under structural pattern as this pattern combines multiple criteria to obtain single criteria 45 Systems modelling – Fabrizio Maria Maggi Filter 46 Systems modelling – Fabrizio Maria Maggi Filter 47 Systems modelling – Fabrizio Maria Maggi Filter 48 Systems modelling – Fabrizio Maria Maggi Filter 49 Systems modelling – Fabrizio Maria Maggi Filter 50 Systems modelling – Fabrizio Maria Maggi Filter 51 Systems modelling – Fabrizio Maria Maggi Filter 52 Systems modelling – Fabrizio Maria Maggi Filter 53 Systems modelling – Fabrizio Maria Maggi Composite Composite pattern composes objects in term of a tree structure to represent part as well as whole hierarchy This type of design pattern comes under structural pattern as this pattern creates a tree structure of group of objects This pattern creates a class that contains group of its own objects: This class provides ways to modify its group of same objects 54 Systems modelling – Fabrizio Maria Maggi Composite 55 Systems modelling – Fabrizio Maria Maggi Composite 56 Decorator Decorator pattern allows a user to add new functionality to an existing object without altering its structure This type of design pattern comes under structural pattern as this pattern acts as a wrapper to existing class This pattern creates a decorator class which wraps the original class and provides additional functionality keeping class methods signature intact 57 Systems modelling – Fabrizio Maria Maggi Decorator 58 Systems modelling – Fabrizio Maria Maggi Decorator 59 Systems modelling – Fabrizio Maria Maggi Decorator 60 Systems modelling – Fabrizio Maria Maggi Decorator 61 Systems modelling – Fabrizio Maria Maggi Decorator 62 Systems modelling – Fabrizio Maria Maggi Facade Facade pattern hides the complexities of the system and provides an interface to the client using which the client can access the system This type of design pattern comes under structural pattern as this pattern adds an interface to existing system to hide its complexities This pattern involves a single class which provides simplified methods required by client and delegates calls to methods of existing system classes 63 Systems modelling – Fabrizio Maria Maggi Facade 64 Systems modelling – Fabrizio Maria Maggi Facade 65 Systems modelling – Fabrizio Maria Maggi Facade 66 Systems modelling – Fabrizio Maria Maggi Facade 67 Systems modelling – Fabrizio Maria Maggi Categories of Design Patterns 68 Command Command pattern is a data driven design pattern and falls under behavioral pattern category A request is wrapped under an object as command and passed to invoker object: Invoker object looks for the appropriate object which can handle this command and passes the command to the corresponding object which executes the command 69 Systems modelling – Fabrizio Maria Maggi Command 70 Systems modelling – Fabrizio Maria Maggi Command 71 Systems modelling – Fabrizio Maria Maggi Command 72 Systems modelling – Fabrizio Maria Maggi Command 73 Systems modelling – Fabrizio Maria Maggi Command 74 Systems modelling – Fabrizio Maria Maggi Iterator Iterator pattern is very commonly used design pattern in Java and .Net programming environment This pattern is used to get a way to access the elements of a collection object in sequential manner without any need to know its underlying representation Iterator pattern falls under behavioral pattern category 75 Systems modelling – Fabrizio Maria Maggi Iterator 76 Systems modelling – Fabrizio Maria Maggi Iterator 77 Iterator 78 Observer Observer pattern is used when there is one-to-many relationship between objects such as if one object is modified, its dependent objects are to be notified automatically Observer pattern falls under behavioral pattern category 79 Systems modelling – Fabrizio Maria Maggi Observer 80 Systems modelling – Fabrizio Maria Maggi Observer 81 Systems modelling – Fabrizio Maria Maggi Observer 82 Systems modelling – Fabrizio Maria Maggi Observer 83 Systems modelling – Fabrizio Maria Maggi Observer 84 Systems modelling – Fabrizio Maria Maggi Observer 85 Systems modelling – Fabrizio Maria Maggi Strategy In Strategy pattern, a class behavior or its algorithm can be changed at run time This type of design pattern comes under behavioral pattern In Strategy pattern, we create objects which represent
Load more

Recommended publications
  • University of Vaasa
    UNIVERSITY OF VAASA FACULTY OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE Arvi Lehesvuo A SOFTWARE FRAMEWORK FOR STORING USER WORKSPACES OF DESKTOP APPLICATIONS Master’s thesis in Technology for the degree of Master of Science in Technology submitted for inspection, Vaasa, June 30, 2012. Supervisor Prof. Jouni Lampinen Instructor M.Sc. Pasi Pelkkikangas 1 TABLE OF CONTENTS page ABBREVIATIONS 3 LIST OF FIGURES 4 TIIVISTELMÄ 5 ABSTRACT 6 1. INTRODUCTION 7 1.1. Company Introduction: Wapice Ltd 8 1.2. Professional Background Statement 9 1.3. The Scope of the Research 9 1.4. Research Questions 10 2. RESEARCH METHODOLOGY 12 2.1. Constructive Research Approach 12 2.2. Research Process as Applied in This Research 13 3. THEORY AND BACKGROUND OF THE STUDY 17 3.1. Introduction to the Subject 17 3.2. History of Object Oriented Programming 17 3.3. Most Central Elements in Object Oriented Programming 19 3.4. More Advanced Features of Object Oriented Programming 25 3.5. Software Design Patterns 27 3.6. Graphical User Interface Programming 34 4. DEVELOPING THE SOLUTION 39 4.1. Identifying the Solution Requirements 39 4.2. Designing Basic Structure for the Solution 43 4.3. Building the Solution as an External Software Component 47 4.4. Storing the User Data 48 4.5. Optimizing Construction for C# 51 2 5. EVALUATING PRACTICAL RELEVANCE OF THE DESIGN 54 5.1. Testing Design by applying it to Different GUI Design Models 54 5.2. Analyzing Results of the User Questionnaire 57 6. CONCLUSIONS AND FUTURE 61 6.1. Practical Contribution 62 6.2.
    [Show full text]
  • A Framework to Support Behavioral Design Pattern Detection from Software Execution Data
    A Framework to Support Behavioral Design Pattern Detection from Software Execution Data Cong Liu1, Boudewijn van Dongen1, Nour Assy1 and Wil M. P. van der Aalst2;1 1Department of Mathematics and Computer Science, Eindhoven University of Technology, 5600MB Eindhoven, The Netherlands 2Department of Computer Science, RWTH Aachen University, 52056 Aachen, Germany Keywords: Pattern Instance Detection, Behavioral Design Pattern, Software Execution Data, General Framework. Abstract: The detection of design patterns provides useful insights to help understanding not only the code but also the design and architecture of the underlying software system. Most existing design pattern detection approaches and tools rely on source code as input. However, if the source code is not available (e.g., in case of legacy software systems) these approaches are not applicable anymore. During the execution of software, tremendous amounts of data can be recorded. This provides rich information on the runtime behavior analysis of software. This paper presents a general framework to detect behavioral design patterns by analyzing sequences of the method calls and interactions of the objects that are collected in software execution data. To demonstrate the applicability, the framework is instantiated for three well-known behavioral design patterns, i.e., observer, state and strategy patterns. Using the open-source process mining toolkit ProM, we have developed a tool that supports the whole detection process. We applied and validated the framework using software execution data containing around 1000.000 method calls generated from both synthetic and open-source software systems. 1 INTRODUCTION latter specifies how classes and objects interact. Many techniques have been proposed to detect design pat- As a common design practice, design patterns have tern instances.
    [Show full text]
  • Lecture 26: Creational Patterns
    Creational Patterns CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 26 — 11/29/2012 © Kenneth M. Anderson, 2012 1 Goals of the Lecture • Cover material from Chapters 20-22 of the Textbook • Lessons from Design Patterns: Factories • Singleton Pattern • Object Pool Pattern • Also discuss • Builder Pattern • Lazy Instantiation © Kenneth M. Anderson, 2012 2 Pattern Classification • The Gang of Four classified patterns in three ways • The behavioral patterns are used to manage variation in behaviors (think Strategy pattern) • The structural patterns are useful to integrate existing code into new object-oriented designs (think Bridge) • The creational patterns are used to create objects • Abstract Factory, Builder, Factory Method, Prototype & Singleton © Kenneth M. Anderson, 2012 3 Factories & Their Role in OO Design • It is important to manage the creation of objects • Code that mixes object creation with the use of objects can become quickly non-cohesive • A system may have to deal with a variety of different contexts • with each context requiring a different set of objects • In design patterns, the context determines which concrete implementations need to be present © Kenneth M. Anderson, 2012 4 Factories & Their Role in OO Design • The code to determine the current context, and thus which objects to instantiate, can become complex • with many different conditional statements • If you mix this type of code with the use of the instantiated objects, your code becomes cluttered • often the use scenarios can happen in a few lines of code • if combined with creational code, the operational code gets buried behind the creational code © Kenneth M. Anderson, 2012 5 Factories provide Cohesion • The use of factories can address these issues • The conditional code can be hidden within them • pass in the parameters associated with the current context • and get back the objects you need for the situation • Then use those objects to get your work done • Factories concern themselves just with creation, letting your code focus on other things © Kenneth M.
    [Show full text]
  • Prof. Catalin Boja, Phd [email protected] Source Code Quality
    Design patterns Prof. Catalin Boja, PhD [email protected] http://acs.ase.ro/software-quality-testing Source code quality Principles for writing the code: • Easy to read / understand - clear • Easy to modify - structured • Easy to reuse • Simple (complexity) • Easy to test • Implement patterns for the standard problem Left: Simply Explained: Code Reuse 2009-12- acs.ase.ro [email protected] 03.By Oliver Widder, Webcomics Geek Aad Poke.2 Source code quality Forces that influence it: • Available time (delivery terms) • Costs • The experience of the programmer • Programmer competences • Specifications clarity • Solution complexity • Change rates for specifications, requirements, team, etc http://khristianmcfadyen.com/ acs.ase.ro [email protected] 3 Anti-Pattern: Big ball of mud “A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape- and-baling-wire, spaghetti- code jungle.” Brian Foote and Joseph Yoder, Big Ball of Mud, September 1997 acs.ase.ro [email protected] 4 Anti-Pattern: Big ball of mud Where from ? Why ? • Throwaway code - Temporary (Prototyping) solutions to be replaced / rewritten • Cut and Paste code • Adapting code by commenting / deleting other solutions • Very short or unrealistic deadlines • Lack of experience • Lack of standards / procedures acs.ase.ro [email protected] 5 Anti-Pattern: Big ball of mud How do you avoid it? • Rewriting the code (Refactoring) to an acceptable maturity level • Use Clean Code Principles • Design Patterns Implementation acs.ase.ro [email protected] 6 Design-pattern • A pattern is a reusable solution for a standard problem in a given context • Facilitates the reuse of architectures and software design • They are not data structures acs.ase.ro [email protected] 7 Design-pattern “A pattern involves a general “..
    [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]
  • Active Object
    Active Object an Object Behavioral Pattern for Concurrent Programming R. Greg Lavender Douglas C. Schmidt [email protected] [email protected] ISODE Consortium Inc. Department of Computer Science Austin, TX Washington University, St. Louis An earlier version of this paper appeared in a chapter in the book ªPattern Languages of Program Design 2º ISBN 0-201-89527-7, edited by John Vlissides, Jim Coplien, and Norm Kerth published by Addison-Wesley, 1996. : Output : Input Handler Handler : Routing Table : Message Abstract Queue This paper describes the Active Object pattern, which decou- 3: enqueue(msg) ples method execution from method invocation in order to : Output 2: find_route(msg) simplify synchronized access to a shared resource by meth- Handler ods invoked in different threads of control. The Active Object : Message : Input pattern allows one or more independent threads of execution Queue Handler 1: recv(msg) to interleave their access to data modeled as a single ob- ject. A broad class of producer/consumer and reader/writer OUTGOING OUTGOING MESSAGES GATEWAY problems are well-suited to this model of concurrency. This MESSAGES pattern is commonly used in distributed systems requiring INCOMING INCOMING multi-threaded servers. In addition,client applications (such MESSAGES MESSAGES as windowing systems and network browsers), are increas- DST DST ingly employing active objects to simplify concurrent, asyn- SRC SRC chronous network operations. 1 Intent Figure 1: Connection-Oriented Gateway The Active Object pattern decouples method execution from method invocation in order to simplify synchronized access to a shared resource by methods invoked in different threads [2]. Sources and destinationscommunicate with the Gateway of control.
    [Show full text]
  • Sample Chapter
    SAMPLE CHAPTER C# in Depth by Jon Skeet Chapter 6 Copyright 2008 Manning Publications brief contents PART 1PREPARING FOR THE JOURNEY ......................................1 1 ■ The changing face of C# development 3 2 ■ Core foundations: building on C# 1 32 PART 2C#2: SOLVING THE ISSUES OF C# 1........................... 61 3 ■ Parameterized typing with generics 63 4 ■ Saying nothing with nullable types 112 5 ■ Fast-tracked delegates 137 6 ■ Implementing iterators the easy way 161 7 ■ Concluding C# 2: the final features 183 PART 3C# 3—REVOLUTIONIZING HOW WE CODE ..................205 8 ■ Cutting fluff with a smart compiler 207 9 ■ Lambda expressions and expression trees 230 10 ■ Extension methods 255 11 ■ Query expressions and LINQ to Objects 275 12 ■ LINQ beyond collections 314 13 ■ Elegant code in the new era 352 vii Implementing iterators the easy way This chapter covers ■ Implementing iterators in C# 1 ■ Iterator blocks in C# 2 ■ A simple Range type ■ Iterators as coroutines The iterator pattern is an example of a behavioral pattern—a design pattern that simplifies communication between objects. It’s one of the simplest patterns to understand, and incredibly easy to use. In essence, it allows you to access all the elements in a sequence of items without caring about what kind of sequence it is— an array, a list, a linked list, or none of the above. This can be very effective for building a data pipeline, where an item of data enters the pipeline and goes through a number of different transformations or filters before coming out at the other end. Indeed, this is one of the core patterns of LINQ, as we’ll see in part 3.
    [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]
  • Skin Vs. Guts: Introducing Design Patterns in the MIS Curriculum Elizabeth Towell and John Towell Carroll College, Waukesha, WI, USA
    Journal of Information Technology Education Volume 1 No. 4, 2002 Skin vs. Guts: Introducing Design Patterns in the MIS Curriculum Elizabeth Towell and John Towell Carroll College, Waukesha, WI, USA [email protected] [email protected] Executive Summary Significant evidence suggests that there is increasing demand for information technology oriented stu- dents who have exposure to Object-Oriented (OO) methodologies and who have knowledge of the Uni- fied Modeling Language (UML). Object-oriented development has moved into the mainstream as the value of reusable program modules is becoming more evident. Building blocks such as software com- ponents and application frameworks allow organizations to bring products to market faster and to adapt to changes more quickly. When only one analysis and design course is required, the study of object-oriented analysis and design is often minimal or left out of the Management Information Systems curriculum. This paper argues for an increased emphasis on object-oriented techniques in the introductory Systems Analysis and Design course. Specifically, it provides guidance for faculty who are considering adding object-orientation to a systems analysis and design course where existing content leaves little time for new topics. In particular, the authors recommend the introduction of two successful, generalized design patterns in the context of adaptation of a software development framework. Where time is limited, coverage of such recurring software problems cannot be comprehensive so it is proposed that students explore two design patterns in depth as opposed to a cursory review of more patterns. Students must first learn or review the OO vocabulary including terms such as classes, inheritance, and aggregation so that the ap- propriate term can be used to discuss the UML relationships among the object model components.
    [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]