Şabloane de Proiectare Daniel POP, Ph.D

2 The Plan Introducing fundamental patterns (today) 18 design patterns will be covered based on the case study presented in the text book (next 8 classes): – Design Patterns: Elements of Reusable Object-Oriented Software Remaining patterns (5) will be presented individually (2 classes) Last 3 classes will be devoted to another case study: Designing a Payroll System

3 Definition A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. [Christopher Alexander, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A Pattern Language. Oxford University Press, New York, 1977] 4 essential elements: –Pattern name –Problem –Solution –Consequences –Implementation

4 Types of Patterns Architectural Patterns: MVC, Layers etc. Design Patterns: Singleton, Observer etc –We’ll do these ones GUI Design Patterns: Window per task, Disabled irrelevant things, Explorable interface etc Database Patterns: decoupling patterns, resource patterns, cache patterns etc. Concurrency Patterns: Double buffering, Lock object, Producer- consumer, Asynchronous processing etc. Enterprise (J2EE) Patterns: Data Access Object, Transfer Objects etc. GRASP (General Responsibility Assignment Patterns): Low coupling/high cohesion, Controller, Law of Demeter (don’t talk to strangers), Expert, Creator etc. Anti-patterns = bad solutions largely observed: God class, Singletonitis, Basebean etc.

5 Types of Design Patterns Based on the type of the problem it addresses (Purpose) –Fundamental –Creational –Structural –Behavioral Bases on the technique it uses (Scope) –Class: uses inheritance –Object: uses object composition Remark: we’ll cover patterns from the text book, but many other design patterns exist as well; also classification may differ from one author to another.

6 Fundamental Patterns Delegation Delegation = Handing of a task over another object Consequences: –Behavior can be changed at run-time (comparing to inheritance that is static) –The ‘delegate’ is hidden to delegator’s clients –More difficult to implement comparing to inheritance

7 Fundamental Patterns Interface Interface – decouples the service provider from its client Consequences: –Programming to abstraction –Easily change the service provider –Transparency for client

8 Fundamental Patterns Abstract Superclass Abstract superclass – ensures consistent behavior for its subclasses Consequences: –Common behavior is consistent over subclasses –Variant behavior is abstract in superclass –Clients are using the abstract superclass

9 Fundamental Patterns Interface and Abstract Superclass Combines Interface and Abstract Superclass patterns Consequences: –Combines the advantages of both patterns –May provide a default behavior for the entire, or just a subset, of the ServiceIF via AbstractService

10 Fundamental Patterns Immutable Object Immutable object – the internal state of the object doesn’t change after its creation Consequences: –Only constructors can change object’s state –All member functions are const functions (in C++) –Any member function that need to change the state will create a new instance –Increase design’s robustness and maintainability Example: –String class in JDK

11 Fundamental Patterns Marker Interface A class implements a marker interface in order to support a semantic attribute of the system Consequences: –Used by utility classes that need a specific behavior from their elements, without requesting a common base class Example: –Cloneable, Serializable in JDK

12 Bibliography esign-Patterns-Elements- Reusable-Object- Oriented/dp/ /r ef=sr_1_1?ie=UTF8&qid= &sr=8-1 irst-Design-Patterns- Elisabeth- Freeman/dp/ /r ef=sr_1_2?ie=UTF8&qid= &sr=8-2