8-GoF pattern 1

Design patterns in architecture CS 619 Introduction to OO Design and Development

!  ! 

A pattern is a recurring solution to a standard problem, in a context. Christopher Alexander, professor of architecture… – 

GoF Patterns (Part 1)

– 

Fall 2013

Patterns in engineering ! 

How do other engineers find and use patterns? –  – 

Mature engineering disciplines have handbooks describing successful solutions to known problems Automobile designers don't design cars from scratch using the laws of physics Instead, they reuse standard designs with successful track records, learning from experience

! 

Software engineers should make use of patterns too. – 

Developing software from scratch is also expensive

Why is what a prof of architecture says relevant to software? “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.”

Definitions ! 

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

! 

Larman: In OO design, a pattern is a named description of a problem and solution that can be applied in new contexts; ideally, a pattern advises us on how to apply the solution in varying circumstances and considers the forces and tradeoffs.

Definitions ! 

Patterns have suggestive names: – 

! 

Design Patterns

Arched Columns Pattern, Easy Toddler Dress Pattern,Star and Plume Quilt etc.

Why Patterns? – 

– 

It help us to understand the concept and keep it in memory It facilitates communication

GoF$Design$Pa-erns$

! 

A design pattern is not a finished design that can be transformed directly into code.

! 

It is a description or template for how to solve a problem that can be used in many different situations.

! 

OO design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Pa-ern$Name$ ! 

A%handle%used%to%describe:% –  –  – 

! 

Each%pa'ern%has%four%essen/al%elements:% –  –  –  – 

Pa'ern%name% Problem% Solu/on% Consequences%

!  !  ! 

a%design%problem% its%solu/ons% its%consequences%

Increases%design%vocabulary,%Enhances% communica/on% Makes%it%possible%to%design%at%a%higher%level%of% abstrac/on% “The%Hardest%part%of%programming%is%coming%up% with%good%variable%[func:on,%and%type]%names.”%

Problem$ !  !  !  ! 

Describes%when%to%apply%the%pa'ern% Explains%the%problem%and%its%context% May%describe%specific%design%problems%and/or% object%structures% May%contain%a%list%of%precondi/ons%that%must%be% met%before%it%makes%sense%to%apply%the%pa'ern%

Solu5on$ ! 

Describes%the%elements%that%make%up%the% –  –  –  – 

!  ! 

design% rela/onships% responsibili/es% collabora/ons%

Does%not%describe%specific%concrete% implementa/on% Abstract%descrip/on%of%design%problems%and%how% the%pa'ern%solves%it%

$

Consequences$ !  ! 

Results%and%tradeKoffs%of%applying%the%pa'ern% Cri/cal%for:% –  –  – 

! 

Design$Space$for$GoF$Pa-erns$

evalua/ng%design%alterna/ves% understanding%costs% understanding%benefits%of%applying%the%pa'ern%

Includes%the%impacts%of%a%pa'ern%on%a%system’s:% –  –  – 

flexibility% extensibility% portability%

Scope: domain over which a pattern applies Purpose: reflects what a pattern does

Facade

Example:$

Facade Pattern defines a simplified interface that makes the subsystems easier to use.

Example$ public class Facade{ public void PerformAction() { Class1A c1a = new Class1A(); Class1B c1b = new Class1B(); Class2A c2a = new Class2A(); Class2B c2b = new Class2B(); int result1a = c1a.Method1A(); int result1b = c1b.Method1B(result1a); int result2a = c2a.Method2A(result1a); c2b.Method2B(result1b, result2a); } } public class Class1A{ public int Method1A() { // Sample code } }

Example$

Example$ public class OrderFacade { private Payment pymt = new Payment(); private Inventory inventry = new Inventory(); public void placeOrder(String orderId) { String step1 = inventry.checkInventory(orderId); String step2 = pymt.deductPayment(orderId); // more work }

Facade$Pa-ern$ Why? !  ! 

Subsystems often get complex as they evolve. % Need to provide a simple interface to many, often small, classes. But not necessarily to ALL classes of the subsystem.

Benefits: ! 

} !  ! 

Facade provides a simple default view good enough for most clients. Facade decouples a subsystem from its clients. A facade can be a single entry point to each subsystem level which allows layering.

Example$ Façade:$Par5cipants$ Façade and subsystem classes

Facade (MortgageApplication) –  – 

! 

Clients communicate with subsystem classes by sending requests to facade.

! 

Facade forwards requests to the appropriate subsystem classes.

– 

Clients do not have direct access to subsystem classes.

– 

! 

knows which subsystem classes are responsible for a request. delegates client requests to appropriate subsystem objects.

Subsystem classes (Bank, Credit, Loan) – 

implement subsystem functionality. handle work assigned by the Facade object. have no knowledge of the facade and keep no reference to it.

$

Adapter$Pa-ern:$Mo5va5on$

Common Mistakes !  !  !  ! 

Facade layer should not be forced and its always optional. Methods in facade layer should not contain only one or two lines which calls the other components. Facade is ‘not’ a layer that imposes security and hides important data and implementation. Subsystems are not aware of facade and there should be no reference for facade in subsystems.

$

Solu5on:$$

Adapter$Pa-ern$ We%define%a%series%of%behaviors%that%all%Shapes%will%have%in% common%in%the%Shape%class%and%then%override%their%behavior%in% the%concrete%classes% %

We%need%to%create%a%shape%class%and%have%the%concrete% classes%of%point,%line,%and%square%derive%from%shape%as%in% the%following%figure:%

What about this?

Create%a%Circle%object%that%encapsulates%XXCircle%by% making%an%XXCircle%object%an%a'ribute%of%the%Circle% class.% %

Example$ class Circle extends Shape { private XXCircle myXXCircle; public Circle () { myXXCircle = new XXCircle(); } void public undisplay() { myXXCircle.undisplayIt(); } void public display() { myXXCircle.displayIt(); } }

Adapter:$$Par5cipants$ :%

!  !  ! 

! 

Client. The client class is that which requires the use of an incompatible type. Target. This is the expected interface for the client class. Adaptee. This class contains the functionality that is required by the client. However, its interface is not compatible with that which is expected. Adapter. This class provides the link between the incompatible Client and Adaptee classes.$

Consequences: Allows%for%preexis/ng%objects%to%fit%into% new%class%structures.% %

$Adapter$ %

Intent:$Match%an%exis/ng%object%beyond%your% control%to%a%par/cular%interface% % Problem:%A%system%has%the%right%data%and% behavior,%but%the%wrong%interface.% % Solu5on:$Provides%a%wrapper%with%the% desired%interface.% %

Adapter:$Pa-ern$Structure$I$

Adapter:$Pa-ern$Structure$II$

$ $Adapter$v.s.$Facade$

%Façade%%Adapter%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Are%there%preexis/ng%classes? % % %%%%Yes %%%%%%Yes% Is%there%an%interface%we%MUST%design%to?%%%%%%%%%%%%%%%%%%No %%%%%%Yes% Does%an%object%need%to%behave%polymorphically?%%%%No%%%%%Probably% Is%a%simpler%interface%needed? % % %%%%Yes %%%%%%%No%

Proxy: Motivation !  !  !  ! 

A document editor that can embed graphical objects in a document. Some graphical objects are expensive to create. Not all of these objects are visible at the same time. Opening a document should be fast.

"  Avoid

creating all the expensive objects at

once. "  Create each expensive object on demand.

Proxy: Solution !  ! 

! 

Use another object, an image proxy, that acts as a stand-in for the real image. The image proxy creates the real image only when the document editor asks it to display itself by invoking its Draw operation. The image proxy might store information about the real image.

Proxy: Solution

Proxy: Participants

! 

The Document Editor should be unaware of the proxy:

! 

! 

Proxy: Class Diagram

Proxy –  Maintains reference that lets proxy access real subject. –  Provides an interface identical to the subject’s. –  Controls access to the real subject, and may be responsible for creating & deleting it. –  Other responsibilities depend on the kind of proxy: !  remote proxy: encoding and transferring request. A local representative. !  virtual proxy: caching information (like ImageProxy) !  protection proxy: check access permissions Subject –  Defines the common interface for RealSubject and Proxy so that Proxy can be used anywhere RealSubject is used. RealSubject –  Defines the real object represented by the Proxy.

Proxy A possible object collaboration diagram at run time:

Proxy: Intent and context !  ! 

Proxy provides a surrogate or placeholder for another object to control access to it Apply Proxy when: –  –  – 

you need a local representative for an object that lives in a different address space (remote proxy). you want to avoid the creation of expensive objects until they are really needed (virtual proxy). you want to control access to an object (protection proxy).

Proxy vs. Adapter ! 

An Adapter provides a different interface to the object it adapts.

! 

In contrast, a Proxy provides the same interface as its subject.

! 

However, a Proxy used for access protection might refuse to perform an operation that the subject will perform, so its interface may be effectively a subset of the subject's.