design principle & patterns by a.surasit samaisut copyrights 2009-2010 : all rights reserved

Design Principle & Patterns by A.Surasit Samaisut

Copyrights 2009-2010 : All Rights Reserved

Recurring Design Purposes

RequirementsAnalysis

Framework DesignArchitecture Design

Detailed Design

Implementation

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


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


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


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

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]

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

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

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

Patterns and Non-Functional Requirements

Patterns are also meant to enhance important nonfunctional properties of the system

• Changeability

• Interoperability

• Efficiency

• Reliability

• Testability

• Reusability

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

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


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


Patterns

Purpose Scope

Behavioral patterns

Creational patterns

Structural patterns

Class patterns

Objects patterns

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

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?

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

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


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)


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


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

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.


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


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(…)

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

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

design principle & patterns by a.surasit samaisut copyrights 2009-2010 : all rights reserved

Documents