Architecture & Design


Microservices - How & Why


MicroService is a hot word in the industry today. Almost everyone wants to migrate their systems to a MicroService based architectures so that they can do wonders with it. But, before we jump in, we should pause to think. Are we just following the crowd? Will this help my product?


Database Design Patterns


Database is an essential component of any real world application. A good database design is imperative for a good application design. To enable a good database design, experts have marked out some of the useful database design patterns.


Visitor Pattern


The behavior of any real world application is dynamic. It changes based on various factors around it. The Visitor pattern helps an object accept the behavior of a visiting class. This makes it easy to plug and play the visitor with the element.


Template Method Pattern


The template method sequentially calls several individual abstract methods within the parent class. The subclasses just need to provide an implementation to these abstract methods.


Strategy Pattern


The strategy pattern helps extract a particular behavior out of a class. It allows you to implement several individual behaviors in external classes that can be assigned to the instance - thus defining its behavior.


State Pattern


In the State design pattern, an object's behavior is changed at runtime - depending on the state. This removes the dependency on the if/else or switch/case conditional logic.


Observer Pattern


The observer pattern is a more formalized form of the event based, publish-subscribe relationship between objects.


Memento Pattern


Everyone has used the undo button. Life would have been impossible without it! Memento pattern provides something similar. It is used to restore state of an object to a previous state.


Mediator Pattern


If the objects interact with each other directly, the system components are tightly-coupled with each other - and that increases maintenance cost. Mediator pattern focuses on providing a mediator between objects for communication


Iterator Pattern


an interpreter is one who translates one language into another. On similar lines, the interpreter pattern is useful when we have data in another language. Here, we need to convert a complex text or byte sequence into useful logic.


Interpret Pattern


an interpreter is one who translates one language into another. On similar lines, the interpreter pattern is useful when we have data in another language. Here, we need to convert a complex text or byte sequence into useful logic.


Command Pattern


In a complex software application, it is not possible (or advisable) to have each module talking to the other. A well designed system should keep them isolated. In such a case, passing information can be a big challenge. The chain of responsibility pattern is the ideal solution to such a problem.


Chain of Responsibility Pattern


In a complex software application, it is not possible (or advisable) to have each module talking to the other. A well designed system should keep them isolated. In such a case, passing information can be a big challenge. The chain of responsibility pattern is the ideal solution to such a problem.


Proxy Pattern


The proxy object provides a kind of transparent wall between the caller and the callee. In the code, this is pretty similar to the adapter or decorator patterns. But the design concept is very different.


Flyweight Design Pattern


The flyweight pattern tries to reduce the number of objects by "reusing" a single instance of the class. That is, it creates a single instance of each type of class and passes a reference to any client that needs to use it.


Façade Pattern


Just having multiple subsystems is not enough. The subsystems should be separate in spirit - not just in code - else an isolation is impossible. If the subsystems are truly independent, then the implementation of one has no relation with that of the other - so long as they follow the agreed interface.


Decorator Pattern


As the name suggests, a Decorator "decorates" a class. The code is pretty similar to a container class. But the concept is different. A decorator is used when we want to add a lot more functionality to the given class - that does not make a case for inheritance.


Composite Pattern


When we think of object oriented programming, we think of inheritance. But inheritance is not always the best way of attacking a problem. Inheritance should be used only when the a class inherits from the other in spirit - not because it has similar functionality.


Bridge Pattern


OOAD is all about separating the abstraction from implementation. The Bridge Pattern takes this a step forward. It encapsulates an implementation class inside of an interface class.


Adapter Pattern


As the name suggests, the Adapter pattern allows us to adapt the available interface to what we need. A voltage adapter helps us obtain 110V out of a 230V socket. Similarly, the Adapter pattern provides for an adapter class that can map the available interface to the required interface.


Abstract Factory Pattern


The Abstract Factory pattern is another level of abstraction above the Factory pattern. The Factory pattern provides for a Factory object that can be used to instantiate product objects based on the parameters. The Factory Method returns objects that are instances of the abstract product class.


Prototype Pattern


There are times when instantiating an object is a very costly operation. It is not possible to go through the entire process again and again. At the same time, we do need many instances of the class. The Prototype pattern is used to address such constraints.


Builder Pattern


One of the principles of good design is that we do not crunch too much complexity into a single unit of the code, and any unit of the code is always focused on a consistent isolated part of the functionality. This is the core inspiration behind the Builder pattern.


Singleton Pattern


This is one of the simplest of the Creation Patterns. Singleton is a class that has only one instance - and cannot have more instances. This is useful when we want to contain a consistent functionality for the entire application.


Factory Method Pattern


There are occasions when it is important to control the instantiation. We might want to ensure instantiation in groups, or we want to limit the number of objects, we want to simplify the API . .


SOLID Design Principles


Experts have identified 5 major principles for Object Oriented programming. These are referred as the SOLID principles. They provide a bunch of best practices to be used while laying out the design of an object oriented module. They help you make a SOLID design that should be able to sustain the changes in requirements.


Object Oriented Design


People often confuse object oriented design with object oriented languages. Object oriented languages only offer features that make it easy to code the object oriented design. Object Orientation is a way of thinking and a design paradigm - that makes the application modules more intuitive and maintainable.


Functional Design Patterns


It is important to understand that functional architecture is not in any way less than object oriented design. It is just another way of looking at the problem. Some problems are simpler with functional design and some with object oriented design. It is very important to identify the difference and apply it accordingly.


Introduction to Design Patterns


One of the most important principles that successful designers follow, is that they do not solve all the problems from first principles. That is impossible! It is very important to use time tested solutions to recurring problems. I learnt this the hard way - and that was when I started learning the basics of design patterns.