Protect your dear ones

Many times you encounter code that reads as follows:


public class OuterClass{

private ContainedClass containedClass;

public ContainedClass getContained(){

return containedClass;

}

}

public class ContainedClass{

public void someMethod(){

// Do something

}

}

Typical usage:


// Usage of the class

OuterClass outerObj = new OuterClass();

ContainedClass containedObj = outerObj.getContained();

containedObj.someMethod();

This is a very common pattern and you’d have surely witnessed it in some form or another. There is something essentially wrong with it. Before I begin, Let me tell you a real life instance first:

Imagine you have a girlfriend. Hmm.. for most of us this is easy. We’ve always only imagined a girlfriend 🙂

Back to the point. Lets say you have a girlfriend. A buddy of your calls one day and asks you for her details.

Your obvious response would be “What do you need to do with her?”

He says he has nothing wrong in mind, he just needs to check on something.

Your response “Tell me what you want checked.. I’ll check and let you know”.

This would be a very typical case of how you’d react on that kind of a request. What are you doing here? You’re trying to protect her from exposing it outside, fearing it may harm her or cause her some trouble. You abstract her out from your friend and act as her messenger at times.

Now lets look back at our piece of code above.

1. The OuterClass contains an instance of ContainedClass.

2. It exposes it completely through the method getContained()

But thats not the kind of thing you did in real life.. didn’t you. You abstracted out the details from the friend who called you up.

You need to follow a similar approach here. Lets have a look at this piece of code. (With the ContainedClass remaining same)


public class OuterClass{

private ContainedClass containedClass;

public void someMethod(){

return containedClass.someMethod();

}

}

Typical usage:


// Usage of the class

OuterClass outerObj = new OuterClass();

outerObject.someMethod();

Here you have abstracted out ContainedClass from rest of the world. It can only be accessed through the OuterClass.

It is also referred to as ‘Law of Demeter”

It has many advantages:

1. It helps build more cohesive units and loosely coupled components.

2. The implementation details are hidden from outer world and can be easily modified if needed.

3. The dependencies on the calling objects are limited. It only depends on OuterClass now.

4. Testing is far easier, since you have less dependencies to satisfy.

Hope you found it useful. Do share if you have any thoughts on the above.

Advertisements

2 thoughts on “Protect your dear ones

  1. Awesome explanation about encapsulation !!! Never heard this example before. It’s a great explanation for n00b’s like me !!! Thanks.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s