Design Principle & Patterns by A.Surasit Samaisut Copyrights : All Rights Reserved

Page  2 Recurring Design Purposes Requirements Analysis Framework Design Architecture Design Detailed Design Implementation

Page  3 What is Design Patterns  Is a general reusable solution to a commonly occurring problem in software design  Is not a finished design that can be transformed directly into code  Is a description or template for how to solve a problem that can be used in many different situations  Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved

Page  4 What is Design Patterns  a standard solution to a common programming problem  a technique for making code more flexible by meet certain criteria  a design or implementation structure that achieves a particular purpose  a high-level programming idiom  shorthand for describing certain aspects of program organization  connections among program components and is the shape of a heap snapshot or object model

Page  5 What is Design Patterns  A pattern is a named abstraction from a concrete form that represents a recurring solution to a particular problem  Patterns = problem/solution pairs in context  Patterns facilitate reuse of successful software architectures and design  Not code reuse Instead, solution/strategy reuse Sometimes, interface reuse “Patterns are discovered, not invented” - Richard Helm

Page  6 What is Design Patterns  Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns which are larger in scope, usually describing an overall pattern followed by an entire system  Not all software patterns are design patterns. For instance, algorithms solve computational problems rather than software design problems

Page  7 Modern Origin of Design Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice” [Christopher Alexander et al., A Pattern Language: Towns, Buildings, Construction. Oxford University Press,1977]

Page  8 Purpose of Design Patterns  A design pattern captures design expertise – patterns are not created from thin air, but abstracted from existing design examples  Using design patterns is reuse of design expertise  Studying design patterns is a way of studying how the “experts” do design

Page  9 Structure of a Pattern  Pattern description should include: Name: should be meaningful Problem: a description of the problem the pattern addresses Context: preconditions under which it can occur Forces: constraints/issues the solution must address Solution: description of static and dynamic relationships among the components of the pattern –A solution should resolve the forces in the given context Plus –Example of use –Related patterns, List of aliases for the pattern –Sample code

Page  10 Patterns = Good Design  Software design patterns are supposed to embody good design practice Abstraction Encapsulation Information hiding Modularisation Separation of concerns High internal cohesion and low external coupling Sufficiency, completeness and primitiveness Separation of policy and implementation Single point of reference Divide and conquer

Page  11 Patterns and Non-Functional Requirements  Patterns are also meant to enhance important nonfunctional properties of the system Changeability Interoperability Efficiency Reliability Testability Reusability

Page  12 Design Patterns – In Practice  Design patterns can speed up the development process by providing tested, proven development paradigms  Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns

Page  13 Categories of Patterns  Design patterns vary in granularity and level of abstraction  By categorizing patterns, it becomes easier to recognize and learn them  Categorized by purpose or scope Purpose reflects what the pattern does Scope specifies if the pattern applies to classes or objects

Page  14 Categories of Patterns  Purpose Creational patterns Structural patterns Behavioral patterns  Scope –Class Patterns: »Deal with relationships between classes or subclasses established through inheritance »These relationships are fixed at compile time –Objects patterns: »Deal with object relationships that can be changed at runtime

Page  15 Categories of Patterns Patterns PurposeScope Behavioral patterns Creational patterns Structural patterns Class patterns Objects patterns

Page  16 How do Design Patterns Solve Design Problems?  The meaning of OO is well-known  The hard part is decomposing the system into objects to exploit: Encapsulation Flexibility, extensibility Ease of modification Performance Evolution Reusability

Page  17 Benefits of Patterns  Shared language of design Increases communication bandwidth Decreases misunderstandings  Learn from experience Becoming a good designer is hard –Understanding good designs is a first step Tested solutions to common problems –Where is the solution applicable? –What are the tradeoffs?

Page  18 Type of Design Pattern  Gamma et al [Ga] have classified each of the design patterns in one of three categories, depending upon whether it has to do with Creational patterns (constructing objects) –Creating a collection of objects in flexible ways Structural patterns (controlling heap layout) –Representing a collection of related objects Behavioral patterns (affecting object semantics) –Capturing behavior among a collection of objects

Page  19 Creational Design Patterns  Creational design patterns help us to design applications involving collections of objects: they allow the creation of several possible collections from a single block of code, but with properties such as Creating many versions of the collection at runtimes Constraining the objects created: for example, ensuring that there is only instance of its class  Concept: create objects in flexible or constrained ways

Page  20 Creational Design Patterns  Concerned with construction of object instances  Separate the operations of an application from the creation of objects  Added flexibility in configuring all aspects of creation Static (compile-time) Dynamic (run-time)

Page  21 Creational Design Patterns  Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes  Builder: Separate construction of a complex object from its representation so that the same construction process can create different representations  Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate. The Factory Method lets a class defer instantiation to subclasses

Page  22 Creational Design Patterns  Prototype: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype  Singleton: Ensure that a class only has one instance, and provide a global point of access to it

Page  23 Creational Design – Singleton Pattern  Problem: How can one design a class that should have only one instance and that can be accessed globally within the application?  Context: In some applications it is important for a class to have exactly one instance. A sales order processing application may be dealing with sales for one company. It is necessary to have a Company object that holds details of the company. Clearly there should only be one such object.  Forces: One approach to making an object globally accessible is to make it a global variable, but this is not good design solution. Another way is not to create an object instance at all but to use only static methods. However this is not extensible to situations when it is desirable to exploit polymorphism on singleton subclasses.

Page  24 Creational Design – Singleton Pattern  Solution: Create a static method getInstance(). When accessed the first time, it creates the object instance and returns a reference to the created object. On subsequent accesses, no additional instance is created, and the reference to the existing object is returned  Company details stored in a class The constructor is defined private to the class The constructor is called within a public static method of the class that ensures only a single object exists

Page  25 Creational Design – Singleton Pattern  Clients call the public method to access the object public class Company { private static Company companyInstance; private Company() { … } public static Company getCompanyInstance(){ if (companyInstance == null) { companyInstance=new Company(); } return companyInstance; } Company.getCompanyInstance().CompanyMethod(…)

Page  26 Structural Design Patterns  Structural design patterns help us to arrange collections of objects in forms such as linked lists or trees.  Concept: represent data structures such as trees with uniform processing interfaces

Page  27 Behavioral Design Patterns  Each behavioral pattern captures a kind of behavior among a collection of objects  Concept: we want to be able to use classes in other applications