Null Object. Motivation There are some cases when a system has to use some functionality and some cases when it doesn't. Let's say we have to implement a class that should send the results to a log file or to the console. But this is just an additional option and the data is logged depending on the configuration values.
If there are cases when the client module does not have to log any data then it has to check the configuration parameter in and if block and then to call or not the Logger class. But as we know the 'if' block is not an elegant solution. Intent Provide an object as a surrogate for the lack of an object of a given type. Implementation The participants classes in this pattern are: AbstractClass - defines abstract primitive operations that concrete implementations have to define. Applicability & Examples Example: Log System Let's say we need a logging framework in order to support the logging of an application.
Specific problems and implementation Null Object and Factory Conclusion. Visitor. Motivation Collections are data types widely used in object oriented programming. Often collections contain objects of different types and in those cases some operations have to be performed on all the collection elements without knowing the type. A possible approach to apply a specific operation on objects of different types in a collection would be the use if blocks in conjunction with 'instanceof' for each element. This approach is not a nice one, not flexible and not object oriented at all. We want to create a reporting module in our application to make statistics about a group of customers. Specific problems and implementation Tight Coupled Visitable objects The classic implementation of the Visitor pattern have a major drawback because the type of visitor methods has to be known in advance.
However this type should be known in advance. Visitor Pattern using Reflection Reflection can be used to overcome the main drawback of the visitor pattern. Let's take our example. Hot Points: Template Method. Implementation AbstractClass - defines abstract primitive operations that concrete subclasses define to implement steps of an algorithm.- implements a template method which defines the skeleton of an algorithm. The template method calls primitive operations as well as operations defined in AbstractClass or those of other objects.ConcreteClass - implements the primitive operations to carry out subclass-specific steps of the algorithm.When a concrete class is called the template method code will be executed from the base class while for each method used inside the template method will be called the implementation from the derived class. Applicability & Examples The Template Method pattern should be used:- to implement the invariant parts of an algorithm once and leave it up to subclasses to implement the behavior that can vary.- when refactoring is performed and common behavior is identified among classes.
Example - Application used by a travel agency. Specific problems and implementation. Strategy. Motivation There are common situations when classes differ only in their behavior. For this cases is a good idea to isolate the algorithms in separate classes in order to have the ability to select different algorithms at runtime. Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Implementation Strategy - defines an interface common to all supported algorithms.
ConcreteStrategy - each concrete strategy implements an algorithm. Context contains a reference to a strategy object.may define an interface that lets strategy accessing its data.The Context objects contains a reference to the ConcreteStrategy that should be used. The context object receives requests from the client and delegates them to the strategy object. Applicability & Examples Example - Robots Application Let's consider an application used to simulate and study robots interaction.
Specific problems and implementation. Observer. Motivation We can not talk about Object Oriented Programming without considering the state of the objects. After all object oriented programming is about objects and their interaction. The cases when certain objects need to be informed about the changes occured in other objects are frequent. To have a good design means to decouple as much as possible and to reduce the dependencies. The Observer Design Pattern can be used whenever a subject has to be observed by one or more observers.
Let's assume we have a stock system which provides data for several types of client. Intent Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Implementation The participants classes in this pattern are: Observable - interface or abstract class defining the operations for attaching and de-attaching observers to the client. The flow is simple: the main framework instantiate the ConcreteObservable object. Mediator. Motivation In order to have a good object oriented design we have to create lots of classes interacting one with each other. If certain principles are not applied the final framework will end in a total mess where each object relies on many other objects in order to run. In order to avoid tight coupled frameworks, we need a mechanism to facilitate the interaction between objects in a manner in that objects are not aware of the existence of other objects.
Let's take the example of a screen. Intent Define an object that encapsulates how a set of objects interact. Implementation Participants The participants classes in this pattern are: Mediator - defines an interface for communicating with Colleague objects. Applicability According to Gamma et al, the Mediator pattern should be used when: a set of objects communicate in well-defined but complex ways. Examples Example 1 - GUI Libraries The mediator example is one pattern that is already used in many applications. Example 2 - Chat application. Iterator. Motivation One of the most common data structures in software development is what is generic called a collection. A collection is just a grouping of some objects. They can have the same type or they can be all cast to a base type like object.
A collection can be a list, an array, a tree and the examples can continue. But what is more important is that a collection should provide a way to access its elements without exposing its internal structure. We should have a mechanism to traverse in the same way a list or an array. The idea of the iterator pattern is to take the responsibility of accessing and passing trough the objects of the collection and put it in the iterator object. Intent Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation. The abstraction provided by the iterator pattern allows you to modify the collection implementation without making any changes outside of collection. Implementation Applicability & Examples. Interpreter. Command. “An object that contains a symbol, name or key that represents a list of commands, actions or keystrokes”.
This is the definition of a macro, one that should be familiar to any computer user. From this idea the Command design pattern was given birth. The Macro represents, at some extent, a command that is built from the reunion of a set of other commands, in a given order. Just as a macro, the Command design pattern encapsulates commands (method calls) in objects allowing us to issue requests without knowing the requested operation or the requesting object. Intent - encapsulate a request in an object- allows the parameterization of clients with different requests- allows saving the requests in a queue Implementation The idea and implementation of the Command design pattern is quite simple, as we will see in the diagram below, needing only few extra classes implemented. The Client asks for a command to be executed. Applicability & Examples Let's consider a calculator application. Hot spot.
Chain of Responsibility. Motivation In writing an application of any kind, it often happens that the event generated by one object needs to be handled by another one. And, to make our work even harder, we also happen to be denied access to the object which needs to handle the event. In this case there are two possibilities: there is the beginner/lazy approach of making everything public, creating reference to every object and continuing from there and then there is the expert approach of using the Chain of Responsibility.
The Chain of Responsibility design pattern allows an object to send a command without knowing what object will receive and handle it. The request is sent from one object to another making them parts of a chain and each object in this chain can handle the command, pass it on or do both. Implementation The UML diagram of classes below will help us understand better the way the Chain works. The classic example of the Chain of Responsibility's implementation is presented for us below: Example 1.