Chain of Responsibility Design Pattern

Problem

Consider the case where you have a structural hierarchy of object that is not necessarily subclasses from the same base class. Now lets say there is a piece of functionality that they all can implement, but it is not statically determinate which should handle the case. Now I know that sounds a little complicated, but picture a context sensitive help system. Each piece of the display may have a piece of text that is wants to display when ever the cursor is over top of it, or it may not. In the case where a piece doesn’t want to handle it, you want the class that contains it to display a more general help string. You also want this system to be dynamic at run-time. How can this be done?

Solution

The Chain of responsibility can solve this problem. The chain of responsibility requires that each of the classes involved inherit from a base class, let’s say HelpHandler. Now when they are instantiated, the objects all initialize their parent class with a successor, which is a reference to another object that is also derived from the base class. When the time comes to call the method that you want to pass up the chain, the first object picked is the most appropriate one. If the object doesn’t want (or can’t handle) the request, it calls the BaseClass::Method() which calls the method for the successor, and so on, until one of the objects handles the request.

Consequences

The chain of responsibility makes it so the client doesn’t need know who is in fact handling the request, only that the request is being handled. As well, you can change the hierarchy at run-time to provide for a changing environment. However, it should be noted that in this system all participants in the chain could refuse to handle the request, and the client would not know.

Problem

How can we issue request to other objects in a system, without having to know who will receive the request, or even what the request is? This can be useful for implementing functionality such as a menu system, where each menu item has a command that it executes, but it doesn’t want to know what it is, it only needs to trigger the command at the right time. How can this be done?

Solution

The command pattern is simple the use of objects as commands in a system. The command class has a virtual member called Execute(). In our above example, the menu item could take a command object as an initialization parameter, and when the application runs, then menu item gets a command, the when the menu item is clicked it calls Execute() on the command.

Consequences

Commands are very powerful, and can support a lot of different functionality. For example, if the command registered itself with some global undo class when it executes, then simply by reversing each command in reverse order (I smell a stack…) we can undo any sequence of commands provided every command class can be undone. Command object separates the object that triggers an operation from the one that executes the operation. By using the Composite pattern you can extend a command to execute multiple commands. And since all commands derive from the command base class, adding new commands is easy.

I myself have used this pattern to implement a dynamic console in a game. At run-time, sections of code register commands into the console. The console then accepts textual input, and pattern matches against a Name() method of each command, and upon finding a match it calls Execute() on the command. I had implemented this before discovering Design Patterns, so could have saved myself a lot of work in knowing the intricacies of this pattern if I had read the book.

Strategy Design Pattern

Problem

How can we gain the ability to use different algorithms for like functionality, having the clients contain the code that implements the algorithms? How can we facilitate the extensibility of an algorithm set? How can we use different algorithms without complex conditionals?

Solution

The answer is the strategy. A strategy is a collation of algorithyms each implemented in its own concrete subclass. All the algorithms implement the same result, but may do so differently. Thus a separate class can access the functionality without having to contain it internally.

Consequences

Can implement a range of algorithms each encapsulated and easy to modify.

This provides a way to implement similar functionality without having to subclass the general class, only the algorithm.

One problem is that in order to determine which algorithm to use, the context class must know something about each algorithm.

Strategies increase the number of object in a system, but this can be alleviated by sharing the algorithm classes.

Problem

When an object has different internal states, how can we implement the states without complicated boolean logic inside the class?

Solution

The answer is the state design pattern. In this pattern, the context object contains a state object, which represents the current state that the context object is in. It does this by implementing all the class methods of the context object. Whenever a context object receives a method call, it passes that call on to its state to execute the functionality. The context object changes the state object as needed to correctly relate to its internal state.

Consequences

Encapsulates specific functionality for specific states in its own class

Provides an easy way to extend the functionality of a context class. Just add more states.

State objects can be shared in certain cases to increase reuse.

Mediator Design Pattern

Problem

Partitioning a system can increase reusability. However, if as the number of classes increases then number of interconnections also increase that reduces the reusability. This is because the classes more and more rely on the existence of the others. How can we favor weak coupling and increase reusability?

Solution

A mediator provides and interface, and a level of indirection between dependant classes. A mediator, for instance, can sit between a list box, and a text entry field. When the list box changes, it tells the mediator, who then gets the text from the list box and passes it to the text entry box. So, the text entry box does not need to know about the list box, and does not have any interdependency with it. This is implemented by having both the text entry and list boxes derive off of a colleague base class which has a method Changed() which tells the mediator whenever the box changes. Then the mediator determines what needs to be done to maintain the system functioning properly.

Consequences

Changing how a system of objects interacts requires only subclassing the mediator, and the colleague classes remain unchanged. As well, the mediator provides the one place that controls the object, and determines how they communicate. A mediator also reduces the number of interface methods, as context specific methods are not required.

Problem

When a user interacts with a program, one of the important features is sometimes the ability to undo what was just done. This is common in many applications from graphics to word processing. In fact I just used it now in Microsoft Word. Often it is the case that the operation just executed cannot be reversed appropriately, there is a loss of original information or some other reason. How can we maintain a system that CAN reverse all operations?

Solution

The answer is the memento. A memento is simply a class that contains all information needed to recreate a specific state of an object. When an operation is performed the originator object performs the operation passes back a memento as a side effect. That memento is then stored, and then in the event that the system wishes to return the originator to the old state, then memento is simply passed back to the originator, who adjusts its internal state accordingly. At no time does anyone but the originator know the contents of the memento.

Consequences

Since only the originator know the contents of the memento, no one has to know the implementation details of the originator.

A caretaker object is required to create, store and delete mementos.

Mementos could be very expensive in terms of overhead if the internal state of the originator is complex. So, in some cases mementos might not be a valid solution.

Symmetric and asymmetric clustering is one of the very important topics in SCEA .In last part we had covered , what is asymmetric clustering – part 1.

In this post , we will discuss come questions and concepts on asymmetric clustering.

What kind of applications typically implemented on symmetric clusters might benefit from being refactored into asymmetric ones?

Applications with smaller data sets that experience high request volumes and a relatively high write to read ratio. This kind of application typically doesn’t scale horizontally because of contention between cluster members even using approaches such as optimistic locking.

Applications that require sequenced request handling where a subset of the incoming events must be processed using some sequence or order. This can be implemented more efficiently using partitioning than with approaches using database locking.

Applications that have dynamic messaging requirements. If the set of message queues or topics used by an application changes dynamically during the time the application is deployed then a dynamic POJO message listener framework can be easily constructed with the exact threading model needed by the application rather than the normal cookie cutter approach.

Applications that have very high incoming message rates and where it makes sense to split the incoming message feed so that a specific subset only goes to a single cluster member. We’re partitioning the incoming topics into groups using hashing or some deterministic approach and each cluster member only receives messages for topics assigned to partitions hosted by that cluster member. This cluster member can then aggressively cache state for this subset and this improve performance as well as offloads the database. This again enables horizontal scale up especially when message order is important.

Can you give an example of a large scale application and how you might re-factor it into a partitioned, asymmetric model? Read more…

We had talked about PRINCE2 in our earlier posts.

What is PRINCE2

Understanding PRINCE2 Certification exam

Difference bewteen PMP and PRINCE2 certification

Ikoko has created PRINCE2 Foundation Exam practice test for our readers. This is a mock of PRINCE2 2009 Foundation exam and consists of 50 questions.

Looking forward for your feedback and comments.