Pattern description to Primitives - Analysis - IIT Kanpur · Apply Polymorphism you want to provide a class library of products, and you want to reveal just their interfaces, not

Abstract Factory

Applicability section Requirement Elaboration of requirement Achieved through

tactic(s) a system should be independent of how its products are created, composed, and represented.

Decouple product modules from clients.

Restrict communication paths

a family of related product objects is designed to be used together, and you need to enforce this constraint.

Represent product family. Compose whole from parts

a system should be configured with one of multiple families of products.

Runtime binding of variant module families.

Apply Polymorphism

you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.

Reveal module interface and hide implementation.

Apply Polymorphism

Consequences section It isolates concrete classes. Decouple product modules from

clients. Restrict communication paths

It makes exchanging product families easy. Runtime binding of variant product families.

Apply Polymorphism

It promotes consistency among product families, an application use objects from only one family at a time.

Common interface of variant product families.

Apply Polymorphism

UML structure Tactic UML Reference

Compose whole from parts ConcreteFactory, ProductA, ProductB ConcreteFactory →1..* ProductA, ProductB

Union of services ConcreteFactory.createProductA() ConcreteFactory.createProductB()

Apply Polymorphism AbstractFactory, ConcreteFactory1, ConcreteFactory2 AbstractFactory ↑ ConcreteFactory1 AbstractFactory ↑ ConcreteFactory2

Restrict communication paths Client, ConcreteFactory, ProductA, ProductB Client → ConcreteFactory → ProductA Client → ConcreteFactory → ProductB

Decision view

Builder


tactic(s) the algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled.

Generic implementation of assembling algorithm.

Interface Parameterization

the construction process must allow different representations for the object that's constructed.



Consequences section It lets you vary a product's internal representation.

Variant parts need to be exchangeable at runtime.

Apply Polymorphism

It isolates code for construction and representation.



It gives you finer control over the construction process.

Step-by-step assembling of complex object.

Aggregation of services


Compose whole from parts Director, ConcreteBuilder Director ◊→1..* ConcreteBuilder


// Director.construct() method for all parts { part.buildPart() }

Apply Polymorphism Builder, ConcreteBuilder Builder ↑ ConcreteBuilder

Interface Parameterization Director.construct(Builder[] parts) { … }

Decision view

Factory method


tactic(s) a class can't anticipate the class of objects it must create.

Late/runtime binding of services. Apply Polymorphism

a class wants its subclasses to specify the objects it creates.

Implement variations of the service.

Apply Polymorphism

classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

Abstraction based on variation points.

Generalize service commonality

Consequences section Provides hooks for subclasses. Implement variations of common

interface. Apply Polymorphism


Apply Polymorphism Creator ↑ ConcreteCreator Generalize service commonality // Creator.anOperation() method

.. product = factoryMethod() ..

Decision view

Prototype


tactic(s) the classes to instantiate are specified at run-time, for example, by dynamic loading.

Variant prototype modules need to be exchangeable at runtime.

Apply Polymorphism

to avoid building a class hierarchy of factories that parallels the class hierarchy of products.

Allow self object creation and initialization.

Object cloning

when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

Avoid manually object creation and initialization when a class can have one of only a few different combinations of state.

Object cloning

Consequences section Specifying new objects by varying values. Highly dynamic systems let you define new behavior through object composition—by specifying values for an object's variables.



Reduced subclassing. Avoid factory modules for object creation and initialization.

Allow self object creation and initialization.

Object cloning

Configuring an application with classes dynamically.

Variant prototype modules need to be exchangeable at runtime.

Apply Polymorphism


Object cloning Prototype.clone() Apply Polymorphism Prototype ↑ ConcretePrototype Interface Parameterization Client.operation(Prototype p) {

cloneObj = p.clone() }

Decision view

Singleton


tactic(s) there must be exactly one instance of a class. Joint use of object data Object sharing Sole instance must be accessible to clients from a well-known access point.

-- Static access type

when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

The sole instance is created at runtime but not at compile time so that polymorphism is unaffected.

Null value based object creation

Consequences section Controlled access to sole instance. Hide constructor method. Restrict

communication paths Permits refinement of operations and representation.

The sole instance is created at runtime but not at compile time so that polymorphism is unaffected.


Permits a variable number of instances. Hide constructor method. Restrict communication paths

More flexible than class operations. The sole instance is created at runtime but not at compile time so that polymorphism is unaffected.




// Singleton.getInstance() method if(uniqueInstance == null) uniqueInstance = new Singleton(); else return uniqueInstance;

Static access type static getInstance(); Preprocessing module Singleton.getInstance() {

if(uniqueInstance == null) uniqueInstance = new Singleton(); }

Restrict communication paths Client → Singleton.getInstance() → Singleton.Singleton() Decision view

Adapter


tactic(s) you want to use an existing class, and its interface does not match the one you need.

Overcome mismatch in interface signature.

Interface mapping

you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.

Overcome mismatch in interface signature.

Interface mapping

(object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

Access the services of provider module without subclassing.

Preprocessing module

Consequences section Enables clients to call operations on Adaptee object.

Redirected access between Client and Adaptee objects.



Interface mapping Adapter.request() { Adaptee.specificRequest() }

Apply Polymorphism Target ↑ Adapter Class adapter: Subclass delegation Object adapter: Preprocessing module

Adaptee ↑ Adapter AND Adapter.request() { specificRequest() } Adapter → Adaptee AND Adapter.request() { Adaptee.specificRequest() }

Restrict communication paths Client → Adpter → Adaptee Decision view

Class Adapter:

Object Adapter:

Bridge

Applicability section Requirement Elaboration of requirement Achieved through tactic(s)

you want to avoid a permanent binding between an abstraction and its implementation.

Generic implementation of abstraction.


when the implementation must be selected or switched at run-time.

Variant implementor modules need to be exchangeable at runtime.

Apply Polymorphism

both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently.

Extend both abstraction and implementation without affecting existing code.

Subclass delegation

you want to share an implementation among multiple objects (perhaps using reference counting), and this fact should be hidden from the client.

Decoupling of client and implementor modules.


Consequences section The implementation of an abstraction can be configured at run-time.

Variant implementor modules need to be exchangeable at runtime.

Apply Polymorphism

Improved extensibility. You can extend the Abstraction and Implementor hierarchies independently.

Extend both abstraction and implementation without affecting existing code.

Subclass delegation

Hiding implementation details from clients. You can shield clients from implementation details, like the sharing of implementor objects and the accompanying reference count mechanism (if any).

Decoupling of client and implementor modules.



Preprocessing module Abstraction.operation() → Implementor.operationImp() Apply Polymorphism Implementor ↑ ConcreteImplementor Interface Parameterization Abstraction.operation(Implementor imp) {

imp.operationImp() }

Subclass Delegation Abstraction ↑ RefinedAbstraction AND RefinedAbstraction.refinedOperation() { operation() }

Restrict communication paths Client → Abstraction → ConcreteImplementor Decision view

Composite


tactic(s) you want to represent part-whole hierarchies of objects.

Encapsulate part-whole hierarchies of objects.

Compose whole from parts

you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

Composite and primitive modules provide uniform interface.

Apply Polymorphism

defines class hierarchies consisting of primitive objects and composite objects.

Encapsulate part-whole hierarchies of objects.


Consequences section makes the client simple. Clients can treat composite structures and individual objects uniformly.

Composite and individual modules provide uniform interface.

Apply Polymorphism

makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code.

Composite and Leaf modules provide uniform interface.

Apply Polymorphism


Compose whole from parts Composite, Component Composite ◊→1..* Component

Container interface

Component.add(Component) Component.remove(Component) Component.getChild(int)


// Composite.operation() method for all parts { part.operation() }

Interface Parameterization Composite.operation(Component[] parts) { … }

Apply Polymorphism

Component, Composite, Leaf Component ↑ Composite Component ↑ Leaf

Decision view

Decorator


tactic(s) to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.

Add responsibilities to individual objects transparently, that is, without affecting other objects.

Add responsibilities to individual objects dynamically.


Interface

Parameterization for responsibilities that can be withdrawn. Add responsibilities to individual

objects transparently. Preprocessing module

when extension by subclassing is impractical.

An alternative to subclassing to add an extension.


Consequences section Decorator pattern provides a way to add responsibilities to objects than can be had with static (multiple) inheritance.

An alternative to subclassing to add an extension.


Decorator offers a pay-as-you-go approach to adding responsibilities.

Add responsibilities to individual objects dynamically.



Preprocessing module Decorator.operation() { addedBehavior() component.operation() }

Interface Parameterization Decorator.operation(Component comp) { }

Apply Polymorphism Component ↑ ConcreteComponent Decision view

Facade


tactic(s) you want to provide a simple interface to a complex subsystem.

-- Union of services

there are many dependencies between clients and the implementation classes of an abstraction.

Decouple subsystem components from clients.


you want to layer your subsystems. Represent subsystem layer. Compose whole from Parts

Consequences section It shields clients from subsystem components.



It promotes weak coupling between the subsystem and its clients.



It doesn't prevent applications from using subsystem classes if they need to.

Provide a simple interface to a complex subsystem.

Union of services


Compose whole from parts Facade →1..* Component Union of services Facade.component1Operation()

Façade.component2Operation() Restrict communication paths Client → Façade → Component

Decision view

Flyweight


tactic(s) An application uses a large number of objects.

Reduce data duplication. Object sharing

Storage costs are high because of the sheer quantity of objects.


Most object state can be made extrinsic. Object state can be managed by memory manager.

Object sharing

Many groups of objects may be replaced by relatively few shared objects.


Consequences section the reduction in the total number of instances.



Object pool search based creation

// FlyweightFactory.getFlyweight() if(flyweightObj exists) { return existing flyweight } else { create new flyweight add it to the pool of flyweights return the new flyweight }

Preprocessing module FlyweightFactory → Flyweight Restrict communication paths Client → FlyweightFactory → Flyweight Interface Parameterization FlyweightFactory.getFlyweight(Flyweight flyweightObj) {

} Apply Polymorphism Flyweight ↑ ConcreteFlyweight

Decision view

Proxy


tactic(s) whenever there is a need for a more versatile or sophisticated reference to an object than a simple pointer.

Additional actions when an object is accessed.

Smart reference

A protection proxy controls access to the original object.

Authenticated access to the object. Credentials based access

A reference count proxy manages the reference count of the object.

-- Count number of references

Consequences section introduces a level of indirection when accessing an object.

Decouple server object from clients.



Preprocessing module Proxy.request() { … realSubject.request() … }

Restrict communication paths Client → Proxy → RealSubject Decision view

Proxy pattern

Protection proxy

Reference count proxy

Chain of Responsibility


tactic(s) more than one object may handle a request, and the handler isn't known a priori. The handler should be ascertained automatically.

Integrate independent modules to support request propagation.

Chaining

you want to issue a request to one of several objects without specifying the receiver explicitly.


Chaining

the set of objects that can handle a request should be specified dynamically.


Chaining

Consequences section Reduced coupling. Decouple handler module from

clients. Restrict communication paths

Added flexibility in distributing responsibilities among objects.


Chaining


Chaining

// ConreteHandler.handleRequest() if can handle { handle request } else { successor.handleRequest() }

Interface Parameterization handleRequest(Handler successor) { }

Apply Polymorphism Handler ↑ ConreteHandler Restrict communication paths Client → aConreteHandler → succesorHandler

Decision view

Command


tactic(s) parameterize objects by an action to perform.

Generic implementation of the action.

Interface parameterization

support undo, queue, logging operations. Support for commonly used primitives.

Library operation

structure a system around high-level operations built on primitive operations.

Reuse primitive operations to build high-level operations.

Library operation

Consequences section Client specifies the receiver of the command. Receiver of the command is

specified at runtime. Interface parameterization

Composite command is assembled from primitive commands.

Reuse primitive operations to build high-level operations.

Library operation


Library operation Command.execute() Apply polymorphism Receiver ↑ ConcreteReceiver Interface parameterization Command.execute (Receiver receiver) {

receiver.action() }

Decision view

Interpreter


tactic(s) Use the Interpreter pattern when there is a language to interpret.

Represent statements in the language

Grammar

Consequences section Because the pattern uses classes to represent grammar rules, you can use inheritance to change or extend the grammar.

Using classes to represent the nonterminals of the grammar.


The Interpreter pattern makes it easier to evaluate an expression.

Interpret individual parts of the sentence separately.



Grammar TerminalExpression, NonterminalExpression Compose whole from parts NonterminalExpression ◊→1..* TerminalExpression Aggregation of services // NonterminalExpression.interpret()

for all parts { part.interpret() }

Apply Polymorphism AbstractExpression ↑ TerminalExpression AbstractExpression ↑ NonterminalExpression

Interface parameterization NonterminalExpression.interpret(AbstractExpression[] parts) { }

Decision view

Iterator


tactic(s) to access an aggregate object's contents without exposing its internal representation.

Provide a simple way to access the elements of an aggregate object sequentially.

Traversal module

to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration).

Variant aggregate modules need to be exchangeable at runtime.

Apply Polymorphism

Consequences section It supports variations in the traversal of an aggregate. Complex aggregates may be traversed in many ways like preorder, postorder.

Provide uniform interface for different traversal algorithms.

Traversal module

Iterators simplify the Aggregate interface. Provide a simple way to access the elements of an aggregate object sequentially.

Traversal module


Traversal module

ConcreteIterator.first() ConcreteIterator.next() ConcreteIterator.isDone() ConcreteIterator.currentItem()

Apply Polymorphism Iterator ↑ ConcreteIterator Interface parameterization ConcreteAggregate.createIterator(Iterator iteratorObj) {

} Decision view

Mediator


tactic(s) a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand.

Additional functionality to handle message passing.

Remote messaging

reusing an object is difficult because it refers to and communicates with many other objects.


Remote messaging

a behavior that's distributed between several classes should be referred without a lot of subclassing.

Objects use message passing as an alternative to subclassing.

Remote messaging

Consequences section It limits subclassing. Objects use message passing as an

alternative to subclassing. Remote messaging

It decouples colleagues. Hide server location from clients. Restrict communication paths

It simplifies object protocols. Additional functionality to handle message passing.

Remote messaging

Making mediation an independent concept and encapsulating it in an object lets you focus on how objects interact apart from their individual behavior.

Separate object communication functionality from individual behavior.



Remote messaging Mediator.sendMsg() { … receiver.receiveMsg() }

Interface Parameterization Mediator.sendMsg(Colleague receiver) { }

Apply Polymorphism Colleague ↑ ConcreteColleague Preprocessing module Mediator → ConcreteColleague Restrict communication paths ConcreteColleague1 → Mediator → ConcreteColleague2

Decision view

Memento


tactic(s) a snapshot of an object's state must be saved so that it can be restored to that state later.

Save a snapshot of object’s state. Restore the object state later.

Checkpoint Rollback

a direct interface to obtaining the state would expose implementation details and break the object's encapsulation.

Authenticated access to the persistence object.

Credentials based access

Consequences section Preserving encapsulation boundaries. Authenticated access to the

persistence object. Credentials based access

It simplifies Originator. Separate checkpoint and rollback functionality from individual behavior.



Checkpoint Originator.createMemento() Rollback Originator.setMemento() Credentials based access Memento.setState()

Memento.getState() Preprocessing module Originator → Memento Restrict communication paths Originator → Memento → Caretaker

Decision view

Observer


tactic(s) When a change to one object requires changing others.

State change in one object requires state change in other objects.

Notify modification

You don't know how many objects need to be changed.

Dependents of an object are known at runtime.

Register at runtime

When an object should be able to notify other objects without making assumptions about who these objects are. In other words, you don't want these objects tightly coupled.

Variant modules need to be exchangeable at runtime.

Apply Polymorphism

Consequences section Abstract coupling between Subject and Observer.

Abstract interface of variant modules is used for coupling.


Support for broadcast communication. Variant modules need to be exchangeable at runtime.

Apply Polymorphism

UML structure

Tactic UML Reference Notify modification Subject.notify() Register at runtime Subject.attach()

Subject.detach() Interface Parameterization Subject.notify(Observer[] observers) {

for all o in observers o.update(); }

Apply Polymorphism Subject ↑ ConcreteSubject Observer ↑ ConcreteObserver

Decision view

State


tactic(s) An object's behavior depends on its state, and it must change its behavior at run-time depending on that state.

Object’s behavior change at runtime.

Apply Polymorphism

Operations have large, multipart conditional statements that depend on the object's state. State pattern puts each branch of the conditional in a separate class.

Encapsulation of multipart conditional branches.

State specialized modules

Consequences section It localizes state-specific behavior and partitions behavior for different states.

Encapsulation of state specific behavior.

State specialized modules

It makes state transitions explicit. Variant state modules need to be exchangeable at runtime.

Apply Polymorphism


State specialized modules ConcreteStateA module ConcreteStateB module

Apply Polymorphism State ↑ ConcreteStateA

State ↑ ConcreteStateB Interface Parameterization Context.request(State state) {

state.handle() }

Decision view

Strategy


tactic(s) provide a way to configure a class with one of many behaviors.

Variant algorithms need to be exchangeable at runtime.

Apply Polymorphism

you need different variants of an algorithm. Implement variations of common interface.

Apply Polymorphism

an algorithm uses data that clients shouldn't know about. Avoid exposing complex, algorithm-specific data structures.

Encapsulation of algorithm specific behavior.

Algorithm specialized modules

a class defines many behaviors, and these appear as multiple conditional statements in its operations.

Variant algorithms need to be exchangeable at runtime.

Apply Polymorphism

Consequences section Family of related algorithms. Encapsulation of algorithm

specific behavior. Algorithm specialized modules

A choice of implementations. Variant algorithms need to be exchangeable at runtime.

Apply Polymorphism


Algorithm specialized modules ConcreteStrategyA module ConcreteStrategyB module

Apply Polymorphism Strategy ↑ ConcreteStrategyA Strategy ↑ ConcreteStrategyB

Interface Parameterization Context.request(Algorithm algorithm) { }

Decision view

Template Method


tactic(s) to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary.

implement the invariant parts of an algorithm once.

leave it up to subclasses to implement the behavior that can vary.


Apply Polymorphism

when common behavior among subclasses should be factored and localized in a common class to avoid code duplication.

Generic implementation of common behavior.


template method calls "hook" operations at specific points, thereby permitting extensions only at those points.

Implement variations of common interface.

Apply Polymorphism

Consequences section Template methods are a fundamental technique for code reuse, they are the means for factoring out common behavior in library classes.

Generic implementation of common behavior.



Generalize service commonality AbstractClass.templateMethod() Apply Polymorphism AbstractClass ↑ ConcreteClass

Decision view

Visitor


tactic(s) an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes.

Variations of the operation on different concrete classes need to be represented.

Enumerate variations

many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid polluting their classes with these operations.

Adding new operations does not affect existing object structure.

Add an individual module

the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes is potentially costly.

Adding new operations does not affect existing object structure.

Add an individual module

Consequences section Visitor makes adding new operations easy. Adding new operations does not

affect existing object structure. Add an individual module

Related behavior is gathered and localized in a visitor.

Variations of the operation on different concrete classes need to be represented.

Enumerate variations


Add an individual module ConcreteVisitor1, ConcreteVisitor2 Enumerate variations ConcreteVisitor.visitConcreteElementA()

ConcreteVisitor.visitConcreteElementB() Apply Polymorphism Visitor ↑ ConcreteVisitor Interface Parameterization ConcreteElement.accept(Visitor v)

Decision view

Layers


tactic(s) Designing a system whose dominant characteristic is a mix of low- and high-level issues, where high-level operations rely on the lower-level ones.

High-level decomposition of the system whose dominant characteristic is a mix of low- and high-level issues.

Multiple Abstraction levels

A typical pattern of communication flow consists of requests moving from high to low level, and answers to requests, incoming data or notification about events traveling in the opposite direction.



Portability to other platforms is desired. Decouple lower abstraction modules from higher abstraction modules.


Several external boundaries of the system are specified a priori, such as a functional interface to which your system must adhere.


Apply Polymorphism

Late source code changes should not ripple through the system.

Decouple lower abstraction modules from higher abstraction modules.


Interfaces should be stable, and may even be prescribed by a standards body.


Apply Polymorphism

Parts of the system should be exchangeable. Variant modules need to be exchangeable at runtime.

Apply Polymorphism

It may be necessary to build other systems at a later date with the same low-level issues as the system you are currently designing.



Similar responsibilities should be grouped to help understandability and maintainability.



Consequences section Reuse of layers. If an individual layer embodies a well-defined abstraction, the layer can be reused in multiple contexts.



Support for standardization. Implement variations of common interface.

Apply Polymorphism

Dependencies are kept local. Decouple lower abstraction modules from higher abstraction modules.


Exchangeability. Individual layer implementations can be replaced by semantically-equivalent implementations.

Variant modules need to be exchangeable at runtime.

Apply Polymorphism


Multiple Abstraction levels Layer 1, Layer 2, …, Layer N Restrict communication paths Layer J+1 → Layer J → Layer J-1 Apply Polymorphism AbstractLayer ↑ Layer

Decision view

Pipes-and-Filters


tactic(s) building a system that process or transform a stream of input data.

High-level decomposition of the system whose characteristic is multi-stage data transformation.

Multiple Processing stages

Future system enhancements should be possible by exchanging processing steps or by recombination of steps.

Variant filter modules need to be exchangeable.

Apply Polymorphism

Small processing steps are easier to reuse in different contexts than large components.

-- Multiple Processing stages

Non-adjacent processing steps do not share information.

Decoupling of non-adjacent processing steps.


Different sources of input data exist, such as a network connection or a hardware sensor. It should be possible to present or store final results in various ways.

Processing stages for input and output transformation of the system.


Explicit storage of intermediate results for further processing in files is error-prone.

Files are not used to share intermediate results between adjacent processing stages.

Request propagation

Consequences section No intermediate files necessary. Files are not used to share

intermediate results between adjacent processing stages.

Chaining

Flexibility by filter exchange. Variant filter modules need to be exchangeable.

Apply Polymorphism

Flexibility by recombination. Abstract coupling between filter modules.


Reuse of filter components. High-level decomposition of the system whose characteristic is multi-stage data transformation.



Multiple Processing stages Filter 1, Filter 2, …, Filter N

Chaining Filter.execAction() { process request successorFilter.execAction() }

Interface Parameterization Filter.execAction(AbstractFilter successorFilter) { }

Apply Polymorphism AbstractFilter ↑ Filter Restrict communication paths Filter J-1 → Filter J → Filter J+1

Decision view

Blackboard


tactic(s) The system processing spans several fields of expertise.

High-level decomposition of the system whose processing spans several fields of expertise.

Multiple Partial problem solvers

problems that do not have a feasible deterministic solution for the transformation of raw data into high-level data structures.

Data-directed dynamic problem solving process.

Heuristics based chaining

In many cases no predetermined strategy exists for how the partial problem solvers should combine their knowledge.



A complete search of the solution space is not feasible in a reasonable time.



Since the domain is immature, you may need to experiment with different algorithms for the same subtask. For this reason, individual modules should be easily exchangeable.

Variant solver modules need to be exchangeable.

Apply Polymorphism

There are different algorithms that solve partial problems. For example, the detection of phonetic segments in the waveform is unrelated to the generation of phrases based on words and word sequences.



Input, as well as intermediate and final results, have different representations, and the algorithms are implemented according to different paradigms.


Apply Polymorphism

Consequences section Experimentation. A complete search of the solution space is not feasible.



Support for changeability and maintainability. The individual knowledge sources, and control algorithm are strictly separated. However, all modules can communicate via the blackboard.

Decoupling of solution steps. Restrict communication paths

Reusable knowledge sources. Knowledge sources are independent specialists for certain tasks.




Multiple Partial problem solvers KnowledgeSource 1, KnowledgeSource 2, …, KnowledgeSource N

Restrict communication paths KnowledgeSource J → Blackboard → KnowledgeSource J+1 Heuristics based chaining KnowledgeSource.execAction()

successor = Controller.nextSource() successor.execAction()

Interface Parameterization nextSource(AbstractKnowledgeSource successor) { }

Apply Polymorphism AbstractKnowledgeSource ↑ KnowledgeSource Decision view

Broker


tactic(s) Your environment is a distributed and possibly heterogeneous system with cooperating components.

High-level decomposition of distributed systems.

Separate communication mechanisms

By partitioning functionality into independent components the system becomes potentially distributable and scalable.



If components handle communication themselves, the resulting system faces several dependencies and limitations.



Services for adding, removing, exchanging, activating and locating components are also needed.

Implement variations of standard communication services.

Apply polymorphism

From a developer's viewpoint, there should essentially be no difference between developing software for centralized systems and developing for distributed ones.

Application level components interact only using provider’s interface.


An application that uses an object should only see the interface offered by the object. It should not need to know anything about the implementation details of an object, or about its physical location.



Components should be able to access services provided by others through remote, location-transparent service invocations.

Hide server location from clients. Restrict communication paths

The architecture should hide system- and implementation-specific details from the users of components and services.



Consequences section Location Transparency. Clients do not need to know where servers are located. Similarly, servers do not care about the location of calling clients.

Hide server location from clients. Restrict communication paths

Changeability and extensibility of components. If servers change but their interfaces remain the same, it has no functional impact on clients.



Reusability. When building new client applications, you can often base the functionality of your application on existing services.




Separate communication mechanisms Application layer – Client, Server Proxy layer – Client-side proxy, Server-side proxy Communication layer – Broker, Bridge

Apply polymorphism AbstractBroker ↑ Broker Restrict communication paths Client → Broker → Server

Decision view

Model-view-controller


tactic(s) Different users place conflicting requirements on the user interface.

Handle multiplicity in user-interface requirements.

Multiple views

The same information is presented differently in different windows, for example, in a bar or pie chart.

Handle multiplicity in user-interface requirements.

Multiple views

Supporting different 'look and feel' standards or porting the user interface should not affect code in the core of the application.

Individual components are designed to be high cohesive modules.

Specialized modules

The display and behavior of the application must reflect data manipulations immediately.

State change in model component requires state change in user interface components.

Notify modification

Changes to the user interface should be easy, and even possible at run-time.

State change in model component requires state change in user interface components.

Notify modification

Consequences section Different user interface for the same model. Handle multiplicity in user-

interface requirements. Multiple views

Synchronized views. State change in model component requires state change in user interface components.

Notify modification

Pluggable views and controllers. View components attach and detach to model component at runtime.

Register at runtime

Exchangeability of ‘look and feel’. Variant view modules need to exchangeable.

Apply Polymorphism

Framework potential. A framework based on MVC implements reusable view and controller components.

Individual components are designed to be high cohesive modules.

Specialized modules


Multiple views View 1, View 2, …, View N Specialized modules Model, Controllers, Views Notify modification Model.notify() Register at runtime Model.attach()

Model.detach() Interface Parameterization Model.notify(AbstractView[] views) {

} Apply Polymorphism AbstractView ↑ View Restrict communication paths View → Controller → Model

Decision view

Presentation-Abstraction-Control


tactic(s) Complex information need to support for multiple levels of Human-Computer interaction.

-- Hierarchy of views

Multiple collaborating agents are organized as tree-hierarchy.

System provides different levels of information processing.


Tree-hierarchy reflects transitive dependencies among agents.

Decouple lower abstraction agents from higher abstraction agents.


Consequences section Support for various stakeholder concerns. Complex information need to

support for multiple levels of Human-Computer interaction.

Hierarchy of views

Separation of concerns. The application is structured as hierarchy of collaborating agents.

System provides different levels of information processing.


Support for change. Source code changes to one agent do not ripple through the system.

Decouple lower abstraction agents from higher abstraction agents.



Hierarchy of views CRUD level interface Spreadsheet level interface Statistical graph level interface

Multiple Abstraction levels Bottom level agents Intermediary level agents Top level agents

Restrict communication paths Top level agent → Intermediary level agent → Bottom level agent Decision view

Microkernel


tactic(s) The application platform must cope with software evolution.

High-level decomposition of evolvable systems.

Separation of functional core

The application platform must allow easy integration of emerging technologies.

Decouple functional core modules to support emulation.


The application platform should be extensible.

High-level decomposition of extensible systems.


The applications in your domain need to support different, but similar, application platforms.


Apply Polymorphism

The applications may be categorized into groups that use the same functional core in different ways, requiring the underlying application platform to emulate existing standards.

Decouple functional core modules to support emulation.


Consequences section Portability. A Microkernel system offers a high degree of portability. In order to migrate a system to a new hardware platform, it is sufficient to migrate the functional core of the system.

Migration of system through functional core.


Extensibility. If you need to implement an additional functionality, all you need to do is add a new external server.

Support extensibility through extension layer of the system.


Separation of policy and mechanism. The microkernel component provides all the mechanisms necessary to enable external servers to implement their policies.

Decompose the system into kernel and extension subsystems.



Separation of functional core External server subsystem Emulator subsystem Microkernel subsystem

Restrict communication paths External server → Emulator → Microkernel Apply Polymorphism PlatformInterface ↑ Microkernel

Decision view

Reflection


tactic(s) Changing software is tedious, error prone, and often expensive. Software which actively supports and controls its own modification can be changed more effectively and more safely.

Support modification of the behavior without changing the code.

Parameter based behavior selection

Adaptable software systems usually have a complex inner structure. To keep change behavior of such systems, we prefer to hide this complexity from maintainers of the system.

Provide a simple control panel for behavior modification.


A uniform mechanism that applies to all kinds of changes is easier to use and understand.



Adapting an application framework for a specific customer.

Support modification of the behavior without changing the code.


Even fundamental aspects of software systems can change, for example the communication mechanisms between components.

Implement variations of common interface to be exchangeable.

Apply Polymorphism

Consequences section No explicit modification of source code. Support modification of the

behavior without changing the code.


Changing a software system is easy. Provide a simple control panel for behavior modification.


Support for many kinds of change. Metaobjects can encapsulate every aspect of system behavior, state and structure.



UML structure

Tactic UML Reference Parameter based behavior selection Meta objects Multiple Abstraction levels Base level

Meta level Behavior selection level

Restrict communication paths Client → Behavior selection level → Meta level Client → Behavior selection level → Base level

Apply Polymorphism AbstractMechanism ↑ Mechanism Decision view

Whole-part


tactic(s) A complex object should either be decomposed into smaller objects, or composed of existing objects, to support reusability, and changeability of structure.

Design complex object from smaller parts.


Clients should see the aggregate object as an atomic object that does not allow any direct access to its constituent parts.

Decouple constituent parts from clients.


Consequences section Changeability of Parts. The Whole encapsulates the Parts and thus conceals them from its clients. This makes it possible to modify the internal structure of the Whole without any impact on clients.

Decouple constituent parts from clients.


Separation of concerns. A Whole-Part structure supports the separation of concerns. Each concern is implemented by a separate Part.



Reusability. Parts of a Whole can be reused in other aggregate objects.




Compose whole from parts Whole ◊→1..* Part

Aggregation of services Whole.service1() { Whole.serviceA1() Whole.serviceB1() … Whole.serviceN1() }

Restrict communication paths Client → Whole → Part Decision view

Master-slave


tactic(s) A Computationally intensive task uses Divide-and-conquer principle.

-- Work partitioning

Clients should not be aware that the calculation is based on the 'divide and conquer' principle.

Hide task processing details from clients.


Neither clients nor the processing of sub-tasks should depend on the algorithms for partitioning work.

Separate work partitioning module from subtask modules.


It can be helpful to use different but semantically-identical implementations for processing sub-tasks.

Variant processing subtasks provide common interface to be exchangeable.

Apply Polymorphism

Consequences section Supports parallel computation. A Computationally intensive task

uses Divide-and-conquer principle.

Work partitioning

Exchangeability. By providing an abstract slave class, it is possible to exchange existing slave implementations.

Variant slave classes provide common interface to be exchangeable.

Apply Polymorphism

Separation of concerns. The introduction of the master separates slave and client code from the code for partitioning work.

Separate work partitioning module from subtask modules.


Eficiency. The Master-Slave pattern for parallel computation enables you to speed up the performance.

A Computationally intensive task uses Divide-and-conquer principle.

Work partitioning


Work partitioning Master.splitWork() Compose whole from parts Master →1..* Slave Aggregation of services // Master.splitWork () method

for all slaves { slave.subService() }

Restrict communication paths Client → Master → Slave Interface Parameterization Master.splitWork(AbstractSlave[] slaves) {

} Apply Polymorphism AbstractSlave ↑ Slave

Decision view

Command processor


tactic(s) You often need to implement services that go beyond the core functionality of the system for the execution of user requests. Examples are request queueing, scheduling and suspension.

Support for commonly used execution primitives.

Execution management library

Different users like to work with an application in different ways.

Different user commands implements variation of common interface.

Apply Polymorphism

Additional services such as scheduling should be implemented consistently for all requests.

Generic implementation of execution management services.


Consequences section Flexibility in the way requests are activated. Different user interface elements for requesting a function can generate the same kind of command object

Different user commands implements variation of common interface.

Apply Polymorphism

Flexibility in the number and functionality of requests. The controller and command processor are implemented independently of the functionality of individual commands.

Generic implementation of execution management services.


Programming execution-related services. The central command processor easily allows the addition of services related to command execution.



Concurrency. Command processor also implements services related to concurrent execution commands such as synchronization.




Execution management library CommandProcessor.queue() CommandProcessor.schedule() CommandProcessor.suspend()

Interface Parameterization CommandProcessor.schedule(AbstractCommand command) { }

Apply Polymorphism AbstractCommand ↑ Command Decision view

View handler


tactic(s) Software systems supporting multiple views often need additional functionality for managing them. open, manipulate, dispose, and coordination of views.

Support for commonly used view management primitives.

View management library

Implementation of view management does not depend individual views implementations.

Generic implementation of view management services.


View implementations can vary, types of views may vary.

Different view modules implements variation of common interface.

Apply Polymorphism

Consequences section Uniform handling of views. Generic implementation of view

management services. Interface Parameterization

Exchangeability of views. Different view modules implements variation of common interface.

Apply Polymorphism


View management library ViewHandler.open() ViewHandler.close() ViewHandler.update() ViewHandler.clone()

Interface Parameterization ViewHandler.update(AbstractView[] views) { }

Apply Polymorphism AbstractView ↑ View Decision view

Forwarder-Receiver


tactic(s) The system should allow the exchangeability of the communication mechanisms.

Exchangeability of communication components.

Apply Polymorphism

The cooperation of components follows a peer-to-peer model, in which a sender only needs to know the names of its receivers.


Remote messaging

Consequences section Efficient inter-process communication. The separation of IPC functionality from peers introduces an additional level of indirection. Compared to the time consumption of the actual IPC, however, this overhead should be negligible in most cases.

Hide location of a remote peer from other peers.


Encapsulation of IPC facilities. All dependencies on concrete IPC facilities are encapsulated within the forwarders and receivers.

Integrate multiple modules to support request propagation.

Chaining


Remote messaging Receiver.receiveRequest() { … Forwarder.sendRequest() }

Forwarder.sendRequest() { … Reeceiver.receiveRequest() }

Chaining Peer 1 → Receiver1 → Forwarder1 → Receiver2 → Peer 2 Restrict communication paths Peer 1 → Forwarder 1 → … → Forwarder N → Peer 2 Apply Polymorphism AbstractForwarder ↑ Forwarder

AbstractReceiver ↑ Receiver Interface Parameterization Forwarder.sendRequest(AbstractReceiver receiver) {

} Decision view

Client-Dispatcher-Server


tactic(s) A component should be able to use a service independent of the location of the service provider.


Remote messaging

The code implementing the functional core of a service consumer should be separate from the code used to establish a connection with service providers.

Separate object communication functionality from individual service providers.


Consequences section Exchangeability of servers. Variant server classes provide

common interface to be exchangeable.

Apply Polymorphism

Location and migration transparency. Decouple server modules from clients.



Remote messaging Dispatcher.sendRequest() { … server.receiveRequest() }

Interface Parameterization Dispatcher.sendRequest(AbstractServer server) { }

Apply Polymorphism AbstractServer ↑ Server Preprocessing module Dispatcher → Server Restrict communication paths Clinet → Dispatcher → Server

Decision view

Publisher-Subscriber


tactic(s) One or more components must be notified about state changes in a particular component.

State change in one object requires state change in other objects

Notify modification

The number and identities of dependent components is not known a priori, or may even change over time.

Dependants of an object are known at runtime

Register at runtime

The publisher and its dependents should not be tightly coupled when introducing a change-propagation mechanism.

Abstract coupling between publisher and subscriber modules


Consequences section Registry. The publisher maintains a registry of currently-subscribed components.

Dependants of an object are known at runtime

Register at runtime

Synchronization. Whenever the publisher changes state, notify method of publisher sends a notification to all its subscribers.

State change in one object requires state change in other objects

Notify modification


Notify modification PublisherSubscriber.notify() Register at runtime PublisherSubscriber.registerSubject()

PublisherSubscriber.unregisterSubject() PublisherSubscriber.registerObserver() PublisherSubscriber.unregisterObserver()

Add an individual module PublisherSubscriber module Interface Parameterization PublisherSubscriber.notify(Observer[] observers) {

} Apply Polymorphism Observer ↑ ConcreteObserver Restrict communication paths Subject → PublisherSubscriber → ConcreteObserver

Decision view

Documents

Pattern description to Primitives - Analysis - IIT Kanpur · Apply Polymorphism you want to provide a class library of products, and you want to reveal just their interfaces, not