Design Patterns v1 0

8/6/2019 Design Patterns v1 0

1/38

Warranty

Management

System

Design Patterns


2/38

Agenda

OOAD UML

Thinking in Objects

Design Patterns

ICONIX Process

2


3/38

3


4/38

Key Terms

Requirement TypeFunctionalNon-Functional

Difference between Analysis & Design

Analysis

Investigation of problem and requirement rather than a solution(Understanding requirement)Do the right thing

DesignConceptual solution to a problem

Do thing right

Difference between Architecture & Design

4


5/38

OOAD

Object Oriented Analysis (OOA)A method of analysis that examines requirements from the perspective of the

classes and objects found in the vocabulary of the problem domain.

Object Oriented Design (OOD)A method of design encompassing the process of object-oriented decomposition

and a notation for depicting logicaland physicalas well as staticand dynamic

models of the system under design.

Object Oriented Decomposition

Process of breaking a system into parts, each of which represents some classor

objectfrom the problem domain.

Responsibility driven design & reusability 5


6/38

Thinking in Objects

Difference between Classand Object

Object Oriented PrinciplesAbstraction essential characteristics of an object that distinguishes it from all other kinds ofobjects in the perspective of the viewerEncapsulationModularityHierarchy

Relationships

Class level relationships vs Object level relationships

Class Level relationships Inheritance

Object Relationships

Association Aggregation

6


7/38

Thinking in Objects

Quality attributes Abstraction

Coupling Strength of association from one object to other

Cohesion Degree of connectivity between the elements of class or object

Static Model & Dynamic Model

7


8/38

UML

A general-purpose notationallanguage forspecifying and visualizingcomplex software,especially object-orientedsystems

Perspectives to Apply UMLConceptual perspective the diagrams are interpreted as describing things in a situation ofthe real world or domain of interest.

Specification (Software) perspective the diagrams describe software abstractions orcomponents with specifications and interfaces, but no commitment to a particularimplementation.

Implementation (Software) perspective the diagrams describe software implementation in aparticular technology.

UML vs. Thinking in Objects

8
http://www.webopedia.com/TERM/U/object_oriented_programming_OOP.htmlhttp://www.webopedia.com/TERM/U/object_oriented_programming_OOP.htmlhttp://www.webopedia.com/TERM/U/object_oriented_programming_OOP.htmlhttp://www.webopedia.com/TERM/U/object_oriented_programming_OOP.html


9/38

Software Engineering Buzzwords and

Relationships

S/wEngineering

Architecture

Design

OOAD

UML

DesignPatterns

ProgrammingLanguage

SDK S/w

DevelopmentKit

Frameworks

APIApplication

ProgrammingInterface

9


10/38

OOAD UML - Design Patterns: Relationship

Class & Object relationshipsAssociation

AggregationComposition

Inheritance

* * *

10


11/38

Design Patterns

PatternA nameddescription of a problem, solution, when to apply the

solution

Named to well-knownproblem/solution pair that can be applied in

new context

Someone has already solved the problem

GOF Patterns - Authors

Erich Gamma

Ralph Johnson

Richard Helm

John Vlissides11


12/38

Design Patterns Guidelines

Patterns dont give you code, they give you general solutions to design problems

Design patterns dont go directly into your code, they go into your BRAIN

Design thinks about how to create flexibledesigns that are maintainable and that cancope with CHANGE

CHANGE IS CONSTANT

Design should Open for extension and close for modificationA class should have only one responsibility

Identify the aspects that vary and separate then from what stays the same

Program for an Interface, not an implementation

Favor composition over inheritance [Delegation vs Inheritance]Composition change behavior at RuntimeHas a (Composition) vs. Is a (Inheritance) relation

12


13/38

Classification of Design Patterns

Creational Patternsdeal with initializing and configuring classes and objects

how am I going to create my objects?

Structural Patterns

deal with decoupling the interface and implementation of classesand objects

how classes and objects are composed to build larger structures

Behavioral Patterns

deal with dynamic interactions among societies of classes andobjects

how to manage complex control flows (communications)

13


14/38

GOF design patterns

Purpose

Creational Structural Behavioral

Scope

ClassFactory Method Adapter Interperter

Object

Abstract

FactoryBuilder

Prototype

Singleton

Adapter

BridgeComposite

Decorator

Facade

Flyweight

Proxy

Chain of Responsibility

CommandIterator

Mediator

Momento

Observer

State

Strategy

Vistor

14


15/38

GOF Creational Patterns

1. Factory Method Pattern (Class)

2. Abstract Factory Pattern

3. Singleton Pattern

4. Builder Pattern

5. Prototype Pattern

15


16/38

1. Factory Method Pattern

Intent (Objective) -

Defines interface for creating an object, but lets

subclassdecide which class to instantiate.

Factory method lets a class defer instantiation to

subclass

Inheritance & abstract method

16


17/38

2. Abstract Factory Pattern


Provides an interface for creating families of related or dependent

objects without specifying their concrete classes

Interface & Object type casting

17


18/38

3. Singleton Pattern


Ensures a class has only one instance, and provide a global pointof access to it

Private/protected constructor & static method

javax.net.ServerSocketFactory

18


19/38


20/38

1. Adapter Pattern

Intent (Objective)

Converts the interface of a class into anotherinterface the client expects.

Adapter lets classes work together that couldntotherwise because of incompatible interfaces.

Composition 20


21/38

2. Faade Pattern


Provides a unified interface to a set of interfaces in a subsystem.

Faade defines a higher level interface that makes the subsystem

easier to use.

Ex. Remote control

21


22/38

3. Composite Pattern


Allows you to compose objects into tree structuresto represent part-wholehierarchies.

Composite lets client treat individual objects andcomposition of objects uniformly.

Menu MenuItem 22


23/38

4. Bridge


Decouple an abstraction from its implementation so that the two can

vary independently

TV and Remote control

23


24/38

GOF Behavioral Patterns

1. Observer Pattern (Class)2. Strategy Pattern

3. Command Pattern

4. State Pattern

5. Template Method Pattern6. Iterator Pattern

7. Mediator Pattern

8. Memento Pattern

9. Visitor Pattern10. Chain Of Responsibility Pattern

11. Interpreter Pattern (Class)

24


25/38

1. Observer Pattern


Defines a one-to-many dependency betweenobjects so that when one object changes state, allof its dependents are notified and updatedautomatically.

Ex. Button Action Listener, Mouse Listener

java.uitl.Observer, Observable

25


26/38

2. Strategy Pattern


Defines a family of algorithms, encapsulates eachone, and makes them interchangeable.

Strategy lets the algorithm vary independently fromclients that use it.

Change behavior at runtime.

Favor composition over inheritance

26


27/38


28/38

4. State Pattern


Allows an object to alter its behavior when it internal state

changes. The object will appear to change its class.

Account Active, Inactive, Suspend etc.,

28


29/38

5. Iterator Pattern


Provides a way to access the elements of an aggregate object

sequentially without exposing its underlying representation

java.util.Iterator, java.util.Collection

29


30/38

6. Chain Of Responsibility

Intent (Objective)

Avoid coupling (decouples) the sender of a request to its receiver by

giving more than one object a chance to handle the request. Chain the

receiving objects and pass the request along the chain until an objecthandles it

Allows you to add or remove responsibilities dynamically by changing

the members or order of the chain

Linked List Data structure

30


31/38


32/38

Class Diagrams Map Out the Structure of the Code

32


33/38

Sequence Diagrams Help Us Allocate Operations (Behavior) to Classes

33


34/38

Robustness (Analysis) Diagrams Close the Gap Between Requirements and

Detailed Design

34


35/38

Referencing Domain Objects by Name Removes Ambiguity from

the Use Cases

35


36/38

The ICONIX ProcessA Streamlined Approach to UML Modeling

36


37/38

37

?


38/38

Thank You!

Documents

Design Patterns v1 0