Showing posts with label design pattern. Show all posts
Showing posts with label design pattern. Show all posts

Wednesday, June 7, 2017

3 wise men on Tell Don't ask

A story on Tell Don't ask Principle

wisemen.jpg

John, Doe, and Marcus are three good friends. They have over 20 years of experience Java/JEE stack and working in IBM, Cognizant and TCS respectively. They have immense experience in design pattern and all the new technologies and respected by their colleague for Exceptional insight on the Technology Stack.
They are planning to go for a vacation in the upcoming weekend to enjoy their spare time with lots of Burger, whiskey, and cooking. John has an Outhouse in a village so they planned to go there by driving.
At last, the day came they pack their Beer, Whiskey, and Burger and headed towards John outhouse it was far away from Town. At evening they reached the outhouse and prepare some snacks for their whiskey and sit together in a round table to enjoy Chicken roast and Whiskey.
Suddenly the power cut happens, The room is so dark that no one can see anything, from outside they can hear the Call of Cricket, Marcus put on his mobile flashlight, now they can see each other.
Doe breaking the silence by saying,
“Oh well, this ambiance is perfect for a horror story can anyone share any real life experience?”
Marcus replied in a witty way
“Umm No, I believe all we are from town and busy with IT industry so sorry can not share any horror experience but can share some Java experience which still frightened me”
John and Doe’s Architect instinct flashed with this proposal.
They said, “ Oh yes what would be more good to discuss about something which frightened us an Architect in this ambiance, it is same as Horror Story :).”

Marcus slowly demonstrated the problem.
Marcus: As an Architect when I design a solution for a problem it always frightened me what we encapsulate and what portion we expose to our client program?
John and Doe Nodded their head.
Marcas Continue with his speech,
There are lots of OOPs principle which says how judiciously you can encapsulate your classes or API from outside world.
Take an Example, The  Tell Don’t Ask principle, It says us always tell to Object, in a layman term instruct Object what to do never query for an internal state and take a decision based on that because then you loose control over the object.
Take a simple example suppose I want to write a Parcel Delivery Service and there are two domain Objects Parcel and Customer so how should we design it.
If I write following code fragments

/**
*
*/
package com.example.basic;

/**
* @author Shamik Mitra
*
*/
public class PercelDeliveryService {
   
   
    public void deliverPercel(Long customerId){
       
        Customer cust = customerDao.findById(customerId);
        List<Percel> percelList = percelDao.findByCustomerId(customerId);
       
        for(Percel percel : percelList){
           
            System.out.println("Delivering percel to " + cust.getCustomerAddress());
            //do all the stuff for delivery
        }
       
    }

}


According to Tell Don’t Ask it is a violation and should be avoided. In Parcel Delivery Service I try to fetch or ask Customer Address so I can perform the delivery operation so here I query the internal state of the Customer.
And why it is dangerous?
If later if the delivery functionality change says now it also include an email address or mobile so I have to expose these details so exposing more and more internal state think about the other services they may also use the same email address or Customer address. Now If I want to change the Customer Address return type String to Address Object then I need to change all services where it has been used, so a gigantic task to perform and increases risk factor of breaking functionality. Another point is as internal state is exposed to many services there is always a risk to pollute the internal state by a service and it is hard to detect which service changed the state. In one word I loose the control over my object as I don’t know which services use/modify my Object internal state. Now if my object is used by the Internal services of a monolith application I can search the usage in IDE and refactor them but If the Object is exposed through an API and This API used by other organization then I am gone, It really hurts our company reputation and as an architect, I would be fired.
So I can say

Action: More you Expose Internal state
Outcome:  Increase coupling, Increases Risk, Increase Rigidity.


Now again look the solution I provided,
Doe chuckled and guess which point Marcus trying to make so he interrupted him and start saying.
Doe: So Marcus you want to tell if we follow Tell Don’t Ask principle then there are couple of ways we can refactor the problem
1. make an association between Customer and Parcel . and it would be lazy loaded and deliver method should be in Customer Object so from the service we call deliver then deliver method fetch parcel list and deliver it, so if the Internal return type change from String to Address only “deliver” method should be affected.
Like this,
/*
*
*/
package com.example.basic;

/**
* @author Shamik Mitra
*
*/
public class ParcelDeliveryService {
   
   
    public void deliverParcel(Long customerId){
       
        Customer cust = customerDao.findById(customerId);
        cust.deliver();
    }

}

public class Customer{

    public void deliver(){
        List<Percel> percelList = getPercelList();
      for(Percel percel : percelList){
           
            System.out.println("Delivering percel to " + this.getCustomerAddress());
            //do all the stuff for delivery
        }
       
    }
}



By doing this I maintain Tell Don’t Ask principle properly and decreases the risk of exposing internal state and free to modify my class attributes as all behaviors are tied locally with attributes a nice way to achieve encapsulation.
2. We can create a command Object where we pass the Parcel details and pass the command object to Customer Model, the delivery method extracts the Parcel list and deliver it to the respective customer.
But both policy breaks another principle that is Single Responsibility Principle, SRP(Single Responsibility Principle) says A class has only one reason to change.
But If I think in a reverse way, why we write Services? Because each service does one job like Person Delivery Service responsible for “delivery parcel related “ operations so it maintains SRP and this service only change if there are any changes in Parcel Delivery mechanism and if it breaks other services will not be affected unless other services depend on it.
But according to Tell Don’t Ask all Customer related behaviors should be moved into Customer class so we can tell /Instruct/command Customer class to do a task. So Now Customer class has much responsibility because all Customer-related service code now goes into Customer Model. So Customer has more reason to change so increase the risk factor of failing.
So Now we are back in the same problem risk factor.
If exposing internal state then the risk for modifying attribute if move all behavior into a class then the risk of modifying functionality break the system.
So SRP and Tell Don’t Ask principle contradict in this context.

John: John nodded his head and started with his husky voice, Yes this is really a problem
not only this, If we want to implement a cache in a service or want to implement Aggregation function like Percell delivery rate charge according to distance or Account type, Find most parcels sent to a locality we use Aggregator service where we ask for internal state and compute the result. So often we break Tell Don’t Ask principle. Even as per current trend, Model Object should be lightweight and should not be coupled with each other. If the business needs an information which distributes over multiple models we can write an aggregator service and query each model and compute the result , so we querying internal state. Think about Spring data.
Now If we look in another perspective, according to the Domain-driven Design, In a Parcel Delivery Context (Bounded context) is Customer responsible for delivering the parcel?
Absolutely not, In that context Delivery Boy is responsible for delivering the parcel to the customer. For that Delivery boy needs Parcel and Customer Model, and in that context only Customer name and Address details required and for parcel Id, parcel name will be required so as per DDD we create an Aggregate Model DeliveryBoy where we have two slick Model Customer and Percell because in this context we don’t need customer other details and parcel other details like customer account details, Customer birthdate etc, Context wise model is changed so no one big model for customer where all attribute and behaviour resides rather small slick models based on bounded context and an Aggregate model querying these slick model and perform the work.
By doing this we can mix and match SRP and Tell Don’t ask. For a service perspective we only tell /command DeliveryBoy Aggregate model to do something, so Service maintains SRP and Tell don’t ask, Our Aggregate model also maintain SRP but querying Customer and Parcel Model to do the operation.

Like



/**
*
*/
package com.example.basic;

/**
* @author Shamik Mitra
*
*/
public class ParcelDeliveryService {
   
   
    public void deliverParcel(Long customerId){
       
        DeliveryBoy boy = new DeliveryBoy();
        boy.deliver(customerId);
    }

}

public class DeliveryBoy{
    Customer cust;// Context driven model
    Percel percel;
    public void deliver(Long id){
        //do stuff
//load customer slick model
//load Percel slick model
//Deliver the same by quering

        }
       
    }
}

Marcus joined and says let's take one step further as DDD insists  Microservice, so in Microservice we try to break a monolith using functional decomposition( A function is a Bounded context in DDD) so one service doing one task maintains SRP principle and if we needed and information which distributes over multiple services we create an Aggregator service and querying individual service and do the task so Microservice often breaks Tell Don’t Ask
Doe joined and says So there is no silver bullet and not all principles are good in all context, Based on the context you have to judge which principles you follow sometimes you need to compromise, may for a specific principle viewpoint your code is bad but for a given context it is optimum.

Principles are generic and they are context free but real life solution are based on context so fit principles based on context not the reverse.

In the meantime Light comes, so John said here we are for fun let stop the discussion and concentrate on Whiskey and Roast !!!!
Everyone agreed and change the topic.
Conclusion : As a Narrator, My question to all viewers, what do you think about the talk they did, is there are any points they left off which needs attention while designing?

Sunday, May 21, 2017

The Hollywood Principle

The Hollywood Principle


Hollywood.jpg



Hollywood Principle says:  "Don't call us, we'll call you"

This little sentence opens up a new viewpoint in Software industries. This is one of the important principles every developer should know.

In this article, we will try to discuss this principle.

"Don't call us, we'll call you" what does it mean?

In layman terms,  you don’t have to bother about when your turns come, when your turns come they will call you.

But What you and they denote here?

To explain "you" and "they" in technical terms first we need to understand How a Software design works.

When we design a software we try to implements two things.

  1. API
  2. Framework.


  1. API:  API used to publish some methods/functions so the caller/user of the API call this method to get some useful information. So caller does not have any action points to take only call methods and get output.
  2. Framework: The Framework is a little bit critical than API. The framework is maintaining an algorithm but it expects the value to be produced by the caller of the Framework. To put it simple way, Framework takes Strategy or Business implementation from the caller and call it when it requires.



By Hollywood principle, we can make Framework works, where you means the Strategy or business implementation, which needs to be fed, and they denote framework engine/implementation which calls fed strategy when required.

Real time Example:

Spring DI: Think about Spring where we declare beans in XML, and Spring container call these beans create Spring beans, inject other beans into it and returns fully configured bean.  So by the help of XML, we feed the strategy and Spring container calls them when required. We often called it Dependency Injection so Hollywood Principle’s another name is IOC(Inversion of Control).

Struts 1.x: Pay attention to Struts 1.x implementation where caller of Struts extends ActionClass and provide  Business implementations in the Action class and Struts framework call those Action class based on the URL mentioned in Struts config file. So here Action class is Strategy and Struts framework invokes it.

Observer pattern/Listener in Swing:  Think about Swing’s actionListener we subscribe to an event like button click, on Blur etc and when this event occurs Swing call our code written in the actionPerformed method.


Apart from this Servlet / EJB all maintains lifecycles so underlying server calls appropriate life cycle method when the servlet or EJB state changed like init, service, destroy or ejbActivate ejbPassivate etc.

We call those methods as Callback methods because Framework call this method we don’t have to call them but we may provide the implementations of those methods if we want to push some strategies in Framework.



Let see a use case where we can use Hollywood principle

Say Cognizant has a Resume upload portal where job seeker uploads their resumes. When there is an On campusing happens in Cognizant they will call them by sending a mail to their inbox.

We can implement the same by Hollywood principle,
Jobseeker uploads their resumes in Job portal and Cognizant send mail to them when an on campusing occurs.
cognizant says : Don’t call me I will call you. :)Hollywood (2).jpg

Let see the implementation.

Assumption : Here I have not introduced any interface for sake of simplicity and not add any complex scenario like a priority, reset, GroupWise mail sending etc. as I just wanted to show How Hollywood principle works.


Resume.java

/**
*
*/
package com.example.hollywood;

/**
* @author Shamik Mitra
*
*/
public class Resume {
    private String email;
    private String name;
    private String content;
    public String getEmail() {
        return email;
    }
    public void setEmail(String email) {
        this.email = email;
    }
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public String getContent() {
        return content;
    }
    public void setContent(String content) {
        this.content = content;
    }
    @Override
    public String toString() {
        return "Resume [email=" + email + ", name=" + name + ", content=" + content + "]";
    }
   
   

}


CognizantJobPortal.java

/**
*
*/
package com.example.hollywood;

import java.util.ArrayList;
import java.util.List;

/**
* @author Shamik Mitra
*
*/
public class CognizantJobPortal {
   
    private static CognizantJobPortal portal = new CognizantJobPortal();
   
    public static CognizantJobPortal get(){
        return portal;
    }
   
    private CognizantJobPortal(){
       
    }
   
   
    private List<Resume> resumeList = new ArrayList<Resume>();
   
    public void uploadContent(String mail ,String name,String content)
    {
        Resume resume = new Resume();
        resume.setName(name);
        resume.setEmail(mail);
        resume.setContent(content);
        resumeList.add(resume);
    }

   
    public void triggercampusing(){
        for(Resume resume : resumeList){
            System.out.println("Sending mail to " + resume.getName() + " at " + resume.getEmail());
        }
    }
}


Test

/**
*
*/
package com.example.hollywood;

/**
* @author Shamik Mitra
*
*/
public class HollywoodTest {
   
    public static void main(String[] args) {
       
        CognizantJobPortal.get().uploadContent("shamik@xyz.com", "Shamik Mitra", "A java developer");
        CognizantJobPortal.get().uploadContent("Ajanta@vvv.com", "Ajanta Mitra", "A PHP developer");
        CognizantJobPortal.get().uploadContent("Swastika@vvv.com", "Swastika Mitra", "A Microservice developer");
        CognizantJobPortal.get().uploadContent("Mayukh@vvv.com", "Mayukh Mitra", "A Network engineer");
        CognizantJobPortal.get().uploadContent("Samir@123.com", "Samir Mitra", "A java Architect");   
        // Now trigger campusing
        CognizantJobPortal.get().triggercampusing();
    }

}

Output:

Sending mail to Shamik Mitra at shamik@xyz.com
Sending mail to Ajanta Mitra at Ajanta@vvv.com
Sending mail to Swastika Mitra at Swastika@vvv.com
Sending mail to Mayukh Mitra at Mayukh@vvv.com
Sending mail to Samir Mitra at Samir@123.com


Please note that in CognizantJobPortal class I maintain a list where uploaded resumes are added. When cognizant triggers a campusing, job portal/framework send the mail to all jobseekers who uploaded the CV to Cognizant.