Design Patterns will make you efficient and will allow you to build better software.
This webinar blog will walk you through the following:
- Know what is Software Design Patterns
- Understand the need of Software Design Patterns
- Communicate among objects with Mediator Pattern
- Distribute Responsibility using Chain of Responsibility Pattern
- Understand Observer Patterns
Software Design Patterns & Gang Of Four (GOF):
Software Design Patterns describe relationship among classes to solve a general and repeatable design problem in a specific context with proven solution. Anyone who knows something about Software Design Patterns will certainly be aware of the book, “Elements of Reusable Object-Oriented Software” written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, popularly known as ‘Gang Of Four’ (GOF).
Classification of Software Design Patterns:
- Just knowing a programming language is not enough to engineer a software application.
- While building an application it’s important that we keep the future requirements and changes in mind, otherwise you will have to change the code that you had written earlier.
- Building a large application is never easy, so it’s very important that you design it correctly and then start coding the application.
- Design Patterns provide efficient techniques to create a flexible application design.
Chain of Responsibility (COR):
- Chain of Responsibility pattern gives more than one object a chance to handle the request.
- Sender of the request does not know which object in the chain will serve its request.
- In Chain of Responsibility pattern, a chain of request handlers is maintained. A handler decides whether it can handle the request or not, if not, it passes the request to the next handler.
Chain of Responsibility – UML Diagram:
Handler: Defines an interface for handling requests.
ConcreteHandler: Handles the requests it is responsible for. If it can’t handle the request, it sends the request to its successor.
Client: Sends commands to the first object in the chain that may handle the command.
Problem statement:
Customer support system is one of the implementations of this pattern, where users call the help desk (L1 support) and tell their problem.
Solution:
- Using Chain of Responsibility simplifies the request object because it does not have to know the chain’s structure and keep direct references to its members.
- In this case, user simply interacts with the help desk and the request internally goes through multiple handlers.
- User does not need to know about the different handlers.
Uses of Chain of Responsibility:
One of the most important uses of Chain of Responsibility pattern is to implement filter mechanism. One filter processes the request and passes it on to the next filter in the chain. Similarly, next filter processes the request and passes on to the next filter in chain.
JavaEE API uses Chain Of Responsibility pattern to implement filter mechanism using the following doFilter() method javax.servlet. Filter#doFilter(ServletRequest request, ServletResponse response, FilterChain chain).
Mediator Pattern:
The Mediator Pattern promotes loose coupling of objects by removing the need for classes to communicate with each other directly. Mediator objects are used to encapsulate and centralize the interactions between classes.
Mediator Pattern simplifies communication in general when a program contains large number of classes that interact. Each class only needs to know how to pass messages to its mediator, rather than to numerous colleagues.
- Mediator: Defines an interface for communicating with colleague objects.
- ConcreteMediator: Knows the colleague classes and keeps a reference to the colleague objects.
- Colleague classes: Keep a reference to its mediator object.
Problem statement:
Suppose you have to create a chat application where multiple users can chat together; rather than each user sending the message directly to other users, we can use Mediator Pattern to implement this design.
Implementing Mediator Pattern:
All GUI applications consist of small components like Windows, Panel etc. Each Panel contains a group of GUI element. These panels have to co-ordinate among themselves. As in this application, whenever a contact is selected from the drop-down box, its details should be updated in the ContactDisplayPanel and ContactEditorPanel. Rather than one panel having reference of all other panels, we can use Mediator Pattern to simplify the communication between panel objects.
Observer Pattern:
There is someone watching you:
Conclusion:
Similarly, there are other Design Patterns to solve majority of the problems that software designers encounter during their day-to-day activities. Design Patterns compliment one’s experience and help them deliver wonderful and successful software designs. They serve as common nomenclature or jargon that architects can easily communicate with others in the software industry. Software design is no more an art. It’s a skill one can learn. And thanks to design patterns!
Questions asked during the webinar:
1. Under which category does Android Patterns or OTP generation password come in?
When you are a designer there is nothing specific to a particular programming language. Android Pattern should be no different. However, we sometimes get confused between a paradigm and a design pattern. A paradigm makes use of specifics of a particular technology to implement a solution. OTP generation password will have various algorithms but not really a pattern.
2. What is agile?
Agile is a software development process. It does not have anything to do with software design pattern.
3. What is the difference between a Command Pattern and Chain of Responsibility?
In Chain of Responsibility, the client is only talking to the first receiver. It does not even know that it is a Chain of Responsibility. Client is not responsible for creating the first handler. It has to be given the handler by some other means. While Command Pattern is a sort of pseudo language. For example, in the file menu when we click on the save button, it does not have any logic of saving the data. It is just a sort of token, which we call command. Command on its own does not have any logic of execution. Command will be executed by the receiver.
4. How will you differentiate between a framework and Design Pattern?
A Design Pattern is something which you have as an abstract. For example, Chain of Responsibility is an abstract solution to some recurring problem. However, framework is concrete. When you say Spring, it is a framework. It is is a collection of many different functionalities that a framework offers. A Design Pattern is a very small contributor to the entire solution. Framework has a very specific goal in its life. For example, Spring will look at inversion of control and dependency injection as a base.
Framework is used as your underlying infrastructure to build your application, while Design Patterns is an abstract solution where you need to implement code in order to get the benefits.
Here’s the PPT presentation:
