Pattern - describes
a solution to a common problem arising within a context by:
·
Naming a recurring design structure
·
Specifying design structure explicitly by
identifying key class/object
·
Abstracting from concrete design elements, e.g.,
problem domain, form factor, vendor, etc.
·
Distilling & codifying knowledge gleaned by
experts from their successful design experiences
Patterns:
- Builder
- Proxy
- Broker
- Command Processor
- Observer
- Layered Architecture
- Strategy
- Abstract Factory
- Wrapper Facade
- Reactor
- Acceptor-Connector
- Template Method Pattern
Ref:
The 23 Gang of Four Design Patterns .. Revisited
Pattern-Oriented Software Architectures for Concurrent and Networked Software
https://dzone.com/articles/java-design-pattern-simplified-part-1-of-django-se
Builder
is GoF Object Creational pattern.
Separate the construction of a complex object from its representation so that the same construction process can create different representations.
Ref:
http://java.dzone.com/news/design-pattern-builder-patternhttps://en.wikipedia.org/wiki/Builder_pattern
http://java.dzone.com/articles/intro-design-patterns-prototype
Proxy
is GoF Object Structural pattern.
Intent: Provide a surrogate or placeholder for another object to control access to it
Applicability: Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide
Structure
Dynamics
Consequences
+ Decoupling client from object location
+ Simplify tedious & error-prone details
- Additional overhead from indirection
- May impose overly restrictive type system
- It’s not possible to entirely shield clients from networking & IPC
Intent: Provide a surrogate or placeholder for another object to control access to it
Applicability: Proxies are useful wherever there is a need for a more sophisticated reference to a object than a simple pointer or simple reference can provide
Structure
Dynamics
Consequences
+ Decoupling client from object location
+ Simplify tedious & error-prone details
- Additional overhead from indirection
- May impose overly restrictive type system
- It’s not possible to entirely shield clients from networking & IPC
Broker
is POSA1 Architectural Pattern.
Intent: Connect clients with remote objects by mediating invocations from clients to remote objects, while encapsulating the details of IPC or network communication
Applicability: Apps need capabilities to support (potentially) remote communication, provide location transparency, handle faults, manage end-to-end QoS, & encapsulate low-level system details
Dynamics
+ Separation of concerns
+ Portability, modularity, reusability, etc.
- Additional time & space overhead
- May complicate debugging & testing
Applicability: Apps need capabilities to support (potentially) remote communication, provide location transparency, handle faults, manage end-to-end QoS, & encapsulate low-level system details
Dynamics
Consequences
+ Location independence+ Separation of concerns
+ Portability, modularity, reusability, etc.
- Additional time & space overhead
- May complicate debugging & testing
Command Processor
Intent: Encapsulate the request for a service as a command object
Applicability:
• Specify, queue, & execute service requests at different times
• Ensure service enhancements don’t break existing code
• Implement additional capabilities (such as undo/redo & persistence) consistently for all requests to a service
Structure & Dynamics
Consequences
+ Allow different users to work with service in different ways via commands
+ Client isn’t blocked for duration of command processing
– Additional programming to handle info passed with commands (cf. Broker)
– Supporting two-way operations requires additional patterns
The Command Processor pattern provides a relatively straightforward means for passing commands asynchronously between threads and/or processes in concurrent & networked software
In contrast, many implementations of Broker use synchronous (blocking) method invocations (Some brokers also support asynchronous method invocations)
is GoF Object Behavioral pattern (POSA1 book contains description of similar Publisher-Subscriber pattern)Applicability:
• Specify, queue, & execute service requests at different times
• Ensure service enhancements don’t break existing code
• Implement additional capabilities (such as undo/redo & persistence) consistently for all requests to a service
Structure & Dynamics
Consequences
+ Allow different users to work with service in different ways via commands
+ Client isn’t blocked for duration of command processing
– Additional programming to handle info passed with commands (cf. Broker)
– Supporting two-way operations requires additional patterns
The Command Processor pattern provides a relatively straightforward means for passing commands asynchronously between threads and/or processes in concurrent & networked software
In contrast, many implementations of Broker use synchronous (blocking) method invocations (Some brokers also support asynchronous method invocations)
Intent: Define a one-to-many dependency between objects so that when one object changes state, all dependents are notified & updated
Applicability:
• An abstraction has two aspects, one dependent on the other
• A change to one object requires changing untold others
• An object should notify unknown other objects
Structure
Dynamics
Consequences
+ Modularity: subject & observers may vary independently
+ Extensibility: can define/add any # of observers
+ Customizability: different observers offer different views of subject
– Unexpected updates: observers don’t know about each other
– Update overhead: too many irrelevant updates
Applicability:
• An abstraction has two aspects, one dependent on the other
• A change to one object requires changing untold others
• An object should notify unknown other objects
Structure
+ Modularity: subject & observers may vary independently
+ Extensibility: can define/add any # of observers
+ Customizability: different observers offer different views of subject
– Unexpected updates: observers don’t know about each other
– Update overhead: too many irrelevant updates
Layered Architecture
is POSA1 Design Pattern.
The Layered architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks Is at a particular level of abstraction.
Ref: http://posa1.blogspot.com/2008/05/layered-architecture-pattern.html
Strategy
(also known as the policy pattern) is a software design pattern, whereby an algorithm's behaviour can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
You can apply this pattern to a multitude of scenarios, such as validating an input with different criteria, using different ways of parsing, or formatting an input.
The strategy pattern consists of three parts:
You can apply this pattern to a multitude of scenarios, such as validating an input with different criteria, using different ways of parsing, or formatting an input.
The strategy pattern consists of three parts:
- An interface to represent some algorithm (the interface Strategy)
- One or more concrete implementations of that interface to represent multiple algorithms (the concrete classes ConcreteStrategyA and ConcreteStrategyB)
- One or more clients that use the strategy objects
Ref: https://en.wikipedia.org/wiki/Strategy_pattern
Abstract Factory
provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme. The client does not know (or care) which concrete objects it gets from each of these internal factories, since it uses only the generic interfaces of their products. This pattern separates the details of implementation of a set of objects from their general usage and relies on object composition, as object creation is implemented in methods exposed in the factory interface.
Ref: https://en.wikipedia.org/wiki/Abstract_factory_pattern
Wrapper Facade
is POSA 2 pattern - A Structural Pattern for Encapsulating Functions within Classes
Intent: Encapsulate low-level functions and data structures within more concise, robust, portable, and maintainable higher-level object-oriented class interfaces.
• Reduce the tedium & increase the type-safety of developing apps, which decreases certain types of accidental complexities
Portability & maintainability
• Shield app developers from non-portable aspects of lower-level APIs
Modularity, reusability, & configurability
• Creates cohesive & reusable class components that can be ‘plugged’ into other components in a wholesale fashion
• e.g., using OO language features like inheritance & parameterized types
• Whenever a portable abstraction is layered on top of an existing API it’s possible to lose functionality
Performance degradation
• Performance can degrade if many forwarding function calls and/or indirections are made per wrapper façade method
Programming language & compiler limitations
• May be hard to define wrapper facades for certain languages due to a lack of language support or limitations with compilers
Known usages:
The Java Virtual Machine (JVM) and various Java foundation class libraries, such as AWT and Swing, provide a set of wrapper facades that encapsulate most of the lowlevel native OS system calls and GUI APIs.
Ref: https://en.wikipedia.org/wiki/Facade_pattern
http://www.cs.wustl.edu/~schmidt/PDF/wrapper-facade.pdf
Intent: Encapsulate low-level functions and data structures within more concise, robust, portable, and maintainable higher-level object-oriented class interfaces.
Benefits
Concise & robust higher-level OO programming interfaces• Reduce the tedium & increase the type-safety of developing apps, which decreases certain types of accidental complexities
Portability & maintainability
• Shield app developers from non-portable aspects of lower-level APIs
Modularity, reusability, & configurability
• Creates cohesive & reusable class components that can be ‘plugged’ into other components in a wholesale fashion
• e.g., using OO language features like inheritance & parameterized types
Limitations
Loss of functionality• Whenever a portable abstraction is layered on top of an existing API it’s possible to lose functionality
Performance degradation
• Performance can degrade if many forwarding function calls and/or indirections are made per wrapper façade method
Programming language & compiler limitations
• May be hard to define wrapper facades for certain languages due to a lack of language support or limitations with compilers
Known usages:
The Java Virtual Machine (JVM) and various Java foundation class libraries, such as AWT and Swing, provide a set of wrapper facades that encapsulate most of the lowlevel native OS system calls and GUI APIs.
Ref: https://en.wikipedia.org/wiki/Facade_pattern
http://www.cs.wustl.edu/~schmidt/PDF/wrapper-facade.pdf
Reactor
-An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events
Intent: The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. Each service in an application may consist of serveral methods and is represented by a separate event handler that is responsible for dispatching service-specific requests. Dispatching of event handlers is performed by an initiation dispatcher, which manages the registered event handlers. Demultiplexing of service requests is performed by a synchronous event demultiplexer.
Intent: The Reactor design pattern handles service requests that are delivered concurrently to an application by one or more clients. Each service in an application may consist of serveral methods and is represented by a separate event handler that is responsible for dispatching service-specific requests. Dispatching of event handlers is performed by an initiation dispatcher, which manages the registered event handlers. Demultiplexing of service requests is performed by a synchronous event demultiplexer.
-An Object Creational Pattern for Connecting and Initializing Communication Services
Intent: The Acceptor-Connector design pattern decouples connection establishment and service initialization in a distributed system from the processing performed once a service is initialized. This decoupling is achieved with three components: acceptors, connectors, and service handlers. A connector actively establishes a connection with a remote acceptor component and initializes a service handler to process data exchanged on the connection. Likewise, an acceptor passively waits for connection requests from remote connectors, establishing a connection upon arrival of such a request, and initializing a service handler to process data exchanged on the connection. The initialized service handlers then perform application-specific processing and communicate via the connection established by the connector and acceptor components.
A Template Method Pattern contains a method that provides the steps of the algorithm. It allows subclasses to override some of the methods.
Intent: The Acceptor-Connector design pattern decouples connection establishment and service initialization in a distributed system from the processing performed once a service is initialized. This decoupling is achieved with three components: acceptors, connectors, and service handlers. A connector actively establishes a connection with a remote acceptor component and initializes a service handler to process data exchanged on the connection. Likewise, an acceptor passively waits for connection requests from remote connectors, establishing a connection upon arrival of such a request, and initializing a service handler to process data exchanged on the connection. The initialized service handlers then perform application-specific processing and communicate via the connection established by the connector and acceptor components.
Template Method Pattern
The template method design pattern is a common solution when you need to represent the outline of an algorithm and have the additional flexibility to change certain parts of it. In other words, the template method pattern is useful when you ind yourself in a situation such as "I’d love to use this algorithm but I need to change a few lines so it does what I want."A Template Method Pattern contains a method that provides the steps of the algorithm. It allows subclasses to override some of the methods.
