Skip to main content

Posts

Showing posts from January 26, 2018

Decorator design pattern

Greetings! Decorator is a structural design pattern. When we need to add extra functionality to an object it is normal to do it through inheritance. Depending on the number of functionalities we may end up higher number of class hierarchy which leads to maintenance nightmare. Using Decorators we can add additional responsibilities using composition at run time. We do not have to modify existing class but we can "decorate" it to add extra functionalities. Inheritance is one form of extension, but not necessarily the best way to achieve flexibility in our designs. "Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub classing for extending functionality." Image source wikipedia Let's see a sample, Classes should be open for extension but closed for modification.

Template method design pattern

Greetings! Template Method pattern is a behavioral pattern. When we have a common steps to do something but some steps vary, we can do it using bunch of if else statements. But the problem is things are tightly coupled and when new things need to be added we have to change our class. This leads our class difficult to main. For these kind of problems Template Method can be used. We can have a super class to handle our common steps and let sub classes to define their own implements. "Defines the skeleton of an algorithm in a method, deferring some steps to sub-classes. Template Method lets sub-classes redefine certain steps of an algorithm without changing the algorithm's structure."                          Image source wikipedia A sample code Don't call us, we'll call you. - allow low-level components to hook themselves into a system, but the high-level components determine when they are need and how.

Singleton design pattern

Greetings! Singleton design pattern is one of the most commonly used pattern. It falls under creational patterns. "Ensure a class only has one instance and provide a global point of access to it." There are multiple ways to create a singleton class. Eagerly initialization - instance of class is always created, whether we use it or not. (anyway we are creating a class to use it aren't we?) Lazily initialization - create the instance at first call. we have to deal with threading issues. Use of a holder - Bill Pugh method. use an inner class to create the instance hence create the instance lazily and can avoid threading issues. There are ways to break singleton behavior by force and few tricks to prevent them. Cloning - implement clone() and throw an exception to prevent this Reflection - throws an exception in constructor to solve this Different class loaders - implement getClass()

Observer design pattern

Greetings! Observer design pattern falls into behavioral category. This is useful when multiple objects(observers) needs to be updated according to another object's changes(subject). Subject and observers are loosely coupled and have no knowledge of each other. Subject(one) -> Observer(many) "Define a one-to-many dependency between objects so that when one object changes state, all its dependencies are notified and updated automatically." Image source wikipedia Strive for loosely coupled designs between objects that interact.

Strategy design pattern

Greetings! Strategy pattern is a behavioral pattern. It is one of the easiest patterns to learn. From wikipedia A class should be configured with an algorithm instead of implementing an algorithm directly. An algorithm should be selected and exchanged at run time. Algorithm here is not necessarily a mathematical algorithm. It is usually defined as a procedure that takes some value as input, performs a finite number of steps and produces some value as output. Simply a method that does a specific thing. "Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it." Image source  wikipedia Let's have a sample, Encapsulate what varies. Favor composition over inheritance. Program to interface, not implementation.