Upload
pankhuree-srivastava
View
688
Download
0
Embed Size (px)
DESCRIPTION
Discusses some software design patterns with example
Citation preview
1
SOFTWARE SOFTWARE
DESIGN DESIGN
PATTERNSPATTERNS
“Descriptions of communicating objects and classes that are
customized to solve a general design problem”
-- Gamma, et. al.
2
The Pattern Name The Problem it solves The Solution it provides The Consequences (good and bad) of
using it
3
4
CHANGES…Patterns should be able to deal with changes.Changes can come from many different sources:
- New vendor
- New Technology
- New views
-New complexity of the application domain.
- Errors
There are 3 types of pattern …
Creational: address problems of creating an object in a flexible way. Separate creation, from operation/use.
Structural: address problems of using O-O constructs like inheritance to organize classes and objects
Behavioral: address problems of assigning responsibilities to classes. Suggest both static relationships and patterns of communication(use cases)
A modifiable design enables
• An iterative and incremental development cycle, which allows Concurrent (aka simultaneous)
development Risk management Flexibility to change
• The software developer to minimize the introduction of new problems when fixing old ones.
• The software developer to deliver more functionality after initial delivery. 6
Low coupling and high cohesion Clear dependencies between classes Explicit assumptions.
How do design patterns help? They are generalized from existing, i.e. proven,
systems.
They provide a shared vocabulary to designers.
They provide examples of modifiable designs.
They use, principally, Abstract classes Delegation & inheritance
7
8
Common architectural patterns
Façade Strategy
Proxy Abstract Factory
Bridge Command
Adapter Composite
9
Patterns Explained
SingletonFaçadeFactoryAdapterBridge
Name: SingletonProblem: How can we guarantee that one and only oneinstance of a class can be created?Context: In some applications it is importantto have exactly one instance of a class, e.g. sales
ofone company.
Forces: Can make an object globally accessible as aglobal variable, but this violates encapsulation.Could use class (static) operations and attributes, butpolymorphic redefinition is not always possible.
Solution:Create a class with a class operation getInstance().When class is first accessed, this creates relevantobject instance and returns object identity to client.On subsequent calls of getInstance(), no newinstance is created, but identity of existing object isreturned.
Singleton
-uniqueInstance-singletonData
+getInstance( )+getSingletonData( )+singletonOperation( )-Singleton( )
Object identifier for singletoninstance, class scope or static
Returns object identifier for unique instance, class-scopeor static
Private constructor only accessiblevia getInstance()
getInstance( ) {if ( uniqueInstance == null ) { uniqueInstance = new Singleton( ) }return uniqueInstance
}
Class Singleton {private static Singleton uniqueInstance = null;private Singleton( ) { .. } // private constructorpublic static Singleton getInstance( ) {
if (uniqueInstance == null)uniqueInstance = new
Singleton(); // call constructor
return uniqueInstance;}
}
Example: Code
To specify a class has only one instance, we make it inherit from Singleton.
+ controlled access to single object instance through Singleton encapsulation
+ Can tailor for any finite number of instances+ namespace not extended by global variables- access requires additional message passing- Pattern limits flexibility, significant redesign if
singleton class later gets many instances
15
A sculpture is singleton
Name: FaçadeProblem: How can we access a large number of classeswith a complex internal interaction in a simplebut safe way?Solution: Introduce a dedicated interface classthat simplifies the view of the class collection.
Provides a unified interface to a set of objects in a subsystem.
A façade defines a higher-level interface that makes the subsystem easier to use (i.e. it abstracts out all the “messy” details)
Façades allow us to provide a closed architecture.
17
Bad!
Good!
Facadesubsystem classes
19
Façade interface to client provides one (or few) method(s) that allows the client to invoke the subsystems services.
<<façade>>SecurityManager
+addAccessRight()+addActor()+addActorRole()+removeActor()
AccessRight
+addAccessRight()
Actor
+addActor()+removeActor()+changeSalary()
ActorRole
+addActorRole()
Method not in Facade
Pattern Name
21
Home Theatre system and compiler are examples of Façade implementation
22
Compiler
compile(s)
Parse Node
create()
Lexical Analysis
getToken()
Code Generator
create()
Parser
generateParseTree()
Optimizer
create()
Compiler
23
Example – Home TheaterLots of classesand interactions,plus many interfaces.
Clients communicate with the subsystem by sending requests to Façade which forwards them to the appropriate subsystem object(s).
Although subsystem objects perform actual work, Façade may have to translate its interface to subsystem interfaces.
Clients that use the Façade don’t have to access its subsystem objects directly.
Usually only one Façade object is required. Thus a Façade object is often a singleton.
Factory pattern can be used with Façade to provide an interface for creating subsystem objects in a subsystem independent way.
Factory can also be used as an alternative to Façade to hide platform-specific classes.
Mediator pattern is similar to Façade in abstracting functionality of classes.
Name: (Abstract) Factory
Problem: Provide an interface for creating
families of related or dependent objects without specifying their concrete classes. Control instantiation Singleton is a special case of Factory
whereonly one object can be created.
AbstractProduct
ConcreteProduct1
AbstractFactory
ConcreteFactory
FactoryMethod()AnOperation()
FactoryMethod()
Product =FactoryMethod()
return newConcreteProduct()
Normally, a single instance of a ConcreteFactory class is created at runtime.
This creates product objects having a particular implementation.
To create different product objects, clients should use a different concrete factory.
AbstractFactory defers creation of product objects to its ConcreteFactory subclasses.
MyClass
createObjectOfRequiredClass():RequiredClass
Factory design pattern
Client RequiredClass
Factory Class Model
create objects
E.g. create objects of different types
We can order a Car and get an Aston Martin, MG, Jaguar etc
We don’t know which factory builds the car, just that they implement CarFactory. Owner has created the actual factory instance.
// we have a reference to ownerCarFactory aFactory = owner.makefactory();Car myCar =aFactory.makeCar(“AstonMartin”);
class BritishFactory implements CarFactory{public Car makeCar(String b) throws Exception {
if(b.equals(“AstonMartin”)) return new AstonMartin();
else if (..) return ..;else throw new Exception(b + “doesn’t
exist”);}
}
Class AstonMartin extends Car {}
Class Jaguar extends Car {}
Interface CarFactory {
Public Car makeCar(String b) throws Exception;
}
33
Aston Martin Jaguar
Abstract Factory classes are often implemented with the Factory Method pattern.
Can also be implemented using the Prototype pattern.
A concrete factory is often a Singleton.
Comments
35
Pattern: Adapter
Suppose a client objects expect a certain interface to be provided by called object.
However, the interface of the called object differs from what the clients expect, and cannot be changed.
How may this situation be improved, i.e. how may the interface satisfy the clients?
36
Transforms the interface of the target class into another interface that the client classes expect.
Adapter lets classes work together that could not otherwise because of incompatible interfaces.
Used to provide a new interface to existing legacy (i.e. old) software components (aka interface engineering, re-engineering).
Adapter also known as a wrapper
37
38
Adapter Patten
Context:
1. Want to use an existing class without modifying it – call it the “legacy” class
2. But context in which you want to use the legacy class requires conformance to a target (i.e. new) interface that is different from that which the legacy provides.
3. However, the target interface and legacy interface are conceptually related.
Solution:
1. Define an adapter class that implements the target interface.2. The adapter class holds a reference (delegates) to the legacy
class. It translates (new) target requests (or method calls) from client classes to (old) legacy requests (or method calls).
39
Participants of the Adapter Pattern
• Target: Defines the application-specific interface that clients use.
• Client: Collaborates with objects conforming to the target interface.
• Legacy: Defines an existing interface that needs adapting.
• Adapter: Adapts the interface of the legacy class to the target interface.
Bind an Adapter class with the Legacy class
The Adapter class implements the ClientInterface expected by the client. It then delegates requests from the client to the Legacy class and performs any necessary conversion.
ClientInterface could be a Java/C# interface, or an abstract class
40
Client
TargetClientInterface
Request()
Legacy
ExistingRequest()
Adapter
Request()
Legacy class
delegationinheritance
41
Interface inheritance is use to specify the interface of the Adapter class – and then delegation is used to reference the Legacy class
Legacy classsupporting old
interface
Class supporting new interface
Inheritance
Delegation
42
Example
Turkeys do not quack, they gobble. Turkeys can fly but for only short distances.
How can we adapt the Turkey class to behave like a Duck class?
43
duck quack becomes turkey gobble
duck fly becomes fivetimes turkey fly
Adapt the Turkey class to have the same interface as Duck.i.e. have methods quack() and fly()
44
Pattern: Bridge
Client objects expect a constant interface to be provided by some called object.
However, the actual implementation of the interface may vary – there may be lots of different implementations, depending on the circumstances.
How may this situation be satisfied?
Use a Bridge pattern to decouple an abstraction from its implementation
so that both can vary independently.
Also known as “handle/body” pattern
Allows different implementations of an interface to be decided upon dynamically.
45
46
Problem- Want to decouple an abstraction (i.e. class interface) from its implementation, allowing them to vary separately.
Context- Want to change implementation details at run-time without impact to clients classes.
Solution- Use delegation from an interface class to an implementation class.
Consequences- Can change (or add) interface without re-implementing.- Can change implementation, but not impact interface for clients.
47
Inheritance
ImplementorAbstractionimplements
ImplementorA ImplementorB
Client
The Abstraction class defines the interface visible to client.
The Implementor class is an abstract implementation that defines the lower-level methods available to Abstraction – namely different “concrete” implementations such as ImplementorA or ImplementorB
Delegation
48
ExampleSupporting multiple Database Vendors with a Bridge
LeagueStoreImplementorLeagueStoreimplements
XML StoreImplementor
SQL Server StoreImplementor
JDBC StoreImplementor
Arena
LeagueStore is the interface class to the pattern
Abstract interfaceprovides common interface
The bridge pattern is used to provide multiple implementations under the same interface.
Decouples an interface from the implementation so that implementation can be substituted, possibly at runtime.
Example: Interface to a component that is incomplete, not yet known, or unavailable during testing
49
50
Consider problem of incrementally developing, testing and integrating subsystems realized by different project teams.
Subsystems may be completed at different times, delaying the integration of all subsystems until the last one has been completed.
To avoid delay, projects often use a stub implementations in place of a specific subsystem so that the integration tests can start even before the subsystems are completed.
51
Example of the bridge pattern
Similarities: Both are used to hide the details of the underlying
implementation. Difference:
The adapter pattern is geared towards making unrelated components work together
Applied to systems after they are designed (reengineering, interface engineering).
A bridge, on the other hand, is used up-front in a design to let abstractions and implementations vary independently.
Engineering of an “extensible system”. New components can be added to the system, even if these
are not known at analysis or system design time.
52