software design patterns
DESCRIPTION
Discusses some software design patterns with exampleTRANSCRIPT
![Page 1: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/1.jpg)
1
SOFTWARE SOFTWARE
DESIGN DESIGN
PATTERNSPATTERNS
![Page 2: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/2.jpg)
“Descriptions of communicating objects and classes that are
customized to solve a general design problem”
-- Gamma, et. al.
2
![Page 3: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/3.jpg)
The Pattern Name The Problem it solves The Solution it provides The Consequences (good and bad) of
using it
3
![Page 4: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/4.jpg)
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
![Page 5: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/5.jpg)
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)
![Page 6: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/6.jpg)
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
![Page 7: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/7.jpg)
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
![Page 8: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/8.jpg)
8
Common architectural patterns
Façade Strategy
Proxy Abstract Factory
Bridge Command
Adapter Composite
![Page 9: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/9.jpg)
9
Patterns Explained
SingletonFaçadeFactoryAdapterBridge
![Page 10: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/10.jpg)
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.
![Page 11: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/11.jpg)
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.
![Page 12: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/12.jpg)
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
}
![Page 13: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/13.jpg)
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
![Page 14: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/14.jpg)
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
![Page 15: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/15.jpg)
15
A sculpture is singleton
![Page 16: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/16.jpg)
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.
![Page 17: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/17.jpg)
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!
![Page 18: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/18.jpg)
Facadesubsystem classes
![Page 19: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/19.jpg)
19
Façade interface to client provides one (or few) method(s) that allows the client to invoke the subsystems services.
![Page 20: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/20.jpg)
<<façade>>SecurityManager
+addAccessRight()+addActor()+addActorRole()+removeActor()
AccessRight
+addAccessRight()
Actor
+addActor()+removeActor()+changeSalary()
ActorRole
+addActorRole()
Method not in Facade
Pattern Name
![Page 21: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/21.jpg)
21
Home Theatre system and compiler are examples of Façade implementation
![Page 22: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/22.jpg)
22
Compiler
compile(s)
Parse Node
create()
Lexical Analysis
getToken()
Code Generator
create()
Parser
generateParseTree()
Optimizer
create()
Compiler
![Page 23: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/23.jpg)
23
Example – Home TheaterLots of classesand interactions,plus many interfaces.
![Page 24: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/24.jpg)
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.
![Page 25: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/25.jpg)
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.
![Page 26: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/26.jpg)
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.
![Page 27: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/27.jpg)
AbstractProduct
ConcreteProduct1
AbstractFactory
ConcreteFactory
FactoryMethod()AnOperation()
FactoryMethod()
Product =FactoryMethod()
return newConcreteProduct()
![Page 28: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/28.jpg)
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.
![Page 29: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/29.jpg)
MyClass
createObjectOfRequiredClass():RequiredClass
Factory design pattern
Client RequiredClass
Factory Class Model
create objects
![Page 30: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/30.jpg)
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.
![Page 31: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/31.jpg)
// 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”);}
}
![Page 32: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/32.jpg)
Class AstonMartin extends Car {}
Class Jaguar extends Car {}
Interface CarFactory {
Public Car makeCar(String b) throws Exception;
}
![Page 33: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/33.jpg)
33
Aston Martin Jaguar
![Page 34: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/34.jpg)
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
![Page 35: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/35.jpg)
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?
![Page 36: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/36.jpg)
36
![Page 37: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/37.jpg)
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
![Page 38: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/38.jpg)
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).
![Page 39: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/39.jpg)
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.
![Page 40: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/40.jpg)
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
![Page 41: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/41.jpg)
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
![Page 42: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/42.jpg)
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?
![Page 43: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/43.jpg)
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()
![Page 44: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/44.jpg)
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?
![Page 45: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/45.jpg)
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
![Page 46: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/46.jpg)
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.
![Page 47: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/47.jpg)
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
![Page 48: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/48.jpg)
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
![Page 49: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/49.jpg)
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
![Page 50: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/50.jpg)
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.
![Page 51: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/51.jpg)
51
Example of the bridge pattern
![Page 52: Software Design Patterns](https://reader033.vdocuments.us/reader033/viewer/2022061214/549c4287b47959bd318b46c5/html5/thumbnails/52.jpg)
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