Design pattern is a fish

Learn to Design a Pattern

Give a man a fish, and you'll feed him for a day. Teach a man to fish, and you've fed him for a lifetime

Introduction

We tend to request for help from our colleagues. If they offer a help as per this saying then we will be ideally independent. But it is up-to us as well, to learn on our own and make an earnest attempt to be independent. Self Learning is best to gain in depth understanding of something. I think Design Patterns might have been shared with an intent of not reinventing the same wheel and quickly using them based on our use cases. On spending enough time in Software Industry I observed that Design Patterns are treated like a Holy Grail of effective Software Development. We should learn to design a code effectively which is AGILE enough to adapt to the changing requirement.

One fine day I was working on a code wherein I wanted to separate the how different messages are structured, built and formatted and how they are sent to other system. I was using the usual json formatter library FasterXML - Jackson. I will explain you briefly what I intended to do and how I did it without the knowledge of a Design Pattern.

Consider that you have to send messages to a system which are having different structure like shown below :

You have to restrict the Developer that they should use a pre-defined and pre-configured Object Mapper. Moreover the basic skeleton code should be abstracted so that developer can focus only on adding new messages with different structure. A typical enterprise application fetches the data from various data sources and maps them. Hence assume that the data is already mapped in some other POJO and we have to extract the relevant data as per our need. I created an abstract class which will have all the skeleton code. Which looks something like this :

I wanted that map should be called before calling writeValueAsString method and wanted that the implementation of the map method will be specific to each message mapper. I was having the knowledge of behavioural abstraction using interfaces but our requirement needed us to ensure that order of call to map method and writeValueAsString method is preserved. Also configuring the ObjectMapper instance as per our need. He I chose an abstract class over interface. Moreover the concept of abstraction using abstract class is to have some abstract entity which will have some state and behaviour which is shared across its children. Interfaces are pure behavioural abstraction hence should be used in those cases only.

Please note below points about this class design :

• Its abstract which means you cannot create instances out of it

• ObjectMapper instance variable if final which means you cannot change that to some other instance anywhere else in the code, once its configured in the constructor of this class

• Map method is abstract and protected ( inheritable ) so that it should be implemented by child classes only and would be accessible in the same package. It will ensure that outside code which lies beyond this package ( a modular approach) would not be able to call the method. We could not make it private otherwise it cannot be overridden. We did not make it package private so that in future we can separate the messages in a different package.

• Format method is final and it calls the map method before calling the object mapper to convert the POJO to a JSON string. It takes the instance reference as itself ( i.e this ). The method is package private so that it should be called from the same package. Ideally used by the Messenger class

That's it ! Now we could easily create messages as per the structure needed by the DestinationSystem. Below are some examples for reference simply to explain how you can use this effectively :

I was checking some of the Behavioural Design Patterns & I stumbled upon the Template Method Design Pattern - Template Method is a behavioural design pattern that allows you to defines a skeleton of an algorithm in a base class and let sub-classes override the steps without changing the overall algorithm's structure. The FormattableMessage is a flavour of this pattern. But in addition to behaviour it also has state for achieving the behaviour. It is having a simple algorithm to map and then format. The Developer is free to map details as per the requirement.

I concluded that if we have strong fundamentals about a language and are clear about what we want to achieve with effective designing skills then we need not rely on the Design Patterns much. Knowing a Design Pattern is good. Understanding it and various uses cases of the same will help you. But if you totally dependent on it then you may not learn to Design a Pattern and will have limited vocabulary of Patterns which you are aware of. One fine day you may be the one who creates anti-pattern.

Knowledge is camouflaged. All you do is explore it with your inquisitive mind.