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. 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. At this point we should think to the Open Close principle and we should remember from there that we can replace if blocks with an abstract class and each concrete class will implement its own operation. 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 However this type should be known in advance. Visitor Pattern using Reflection Let's take our example.
Statefull Visitors. 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. 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.
Mediator. Motivation.
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. 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. Command design pattern provides the options to queue commands, undo/redo actions and other manipulations. 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. 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.