Encapsulation and its best practices.


Now let's discuss encapsulation in detail.

We have already discussed that for Association relationships to be successful; the prerequisite is that the objects participating in the association relationship should be highly encapsulated.

We also know that Encapsulation is a very important because if the objects participating in the association relationship are not highly encapsulated, then the target object is at the risk of losing its existence in the corresponding system.

There are many design patterns which are influenced by encapsulation as a concept and there are many design patterns which basically deal with encapsulation violation. Hence encapsulation as a concept is very important.

For me to explain Encapsulation in a better way, let me give you an example.

I am sure that many times you must have come across encapsulation as a concept. You must have read it in your programming books. And I am also very sure that most of you were not convinced as to why encapsulation was needed.

The reason is that encapsulation as a topic cannot be appreciated at a programming level. Or encapsulation as a topic cannot be appreciated at the lowest level of granularity where you are codifying small little entities.

We know that if at any point of time the internal state or the implementation of the behaviour of a corresponding system is compromised or exposed, then the target object is at the risk of losing its existence which is nothing but encapsulation violation.

Let me give you an example.

Many times in real life, a system is forced to share its internal state or implementation with the outside world. And whenever that happens, encapsulation is violated.

Let me give you an example of training program.
 
Training Program

I am sure all of you must have attended at least one training program in your life.

Do you recollect how a training program typically starts?

I hope you will all agree that it starts with the "Trainer" taking the introduction of all the "Participants".

And why does the Trainer take the participants' introduction?

First let's understand what a Training program is all about.

A training program is nothing but a problem of behavioural change.

Let's take a hypothetical case. You are a participant in one of my training programs on Design patterns.

Now if you are in this class on design patterns, what exactly are you trying to do?

Let's understand, while you are in this training program on design patterns, you are here to acquire a new behaviour called as "Design Patterns", with a deal with your program manager, that you are willing to acquire this behaviour, provided that someone else helps you to make that change on you, without you having to invest anything from your pocket.

If you were willing to incorporate a new behaviour, like Design Patterns, all by yourself, then you could have done it by reading a book like Eric Gama. You wouldn't have needed a training program at all.

But that is not the case. The deal is that you are willing to incorporate the new behaviour provided someone else helps us you to make that change or incorporate that new behaviour, without you having to invest anything from your pocket.

And who is that someone? It is the Trainer.

And when you say that without investing anything from your pocket, you would realise that whenever you attend a training program, you never pay anything. It's basically your company that pays the trainer.

The "Time" that you invest in a training program is also given to you by your manager.

The only thing that you probably pay is "Attention".
 

A training program is an example of "Visitor Design Pattern" and what we are discussing is the technical aspects of Visitor Design Pattern.

When we say that someone should help you to make the change, then please tell me, for any external object to make a change on any other object what is the prerequisite?

Let's come again as to how does a training program start. We already know that it starts with the trainer taking the participants' introduction.

And why does the trainer do it? Why does he take the participants' introduction?

Whenever any external object needs to do a change on any other object, the first thing that the external object needs to know is what is the "Current State" of the object on which the change has to be made.

In my training programs, this is how I go about doing it.

I first ask the participants' name for the referencing purpose.

My next question to them is about their comfort level on the topic of discussion.

I ask this question because it is impossible for me to make any change on them without knowing their "Current state" or the "Internal state". It is technically impossible.

And the moment they disclose their internal state to me, their encapsulation is violated.

When the Trainer asks you for your introduction with respect to your name and your current state, will you not tell him?

If you say No, there is no way that the trainer can make any change on you.

And if you do tell him, then there is a risk of encapsulation getting violated.

Please realise that in any training program that you may have attended, your encapsulation was violated and you were in serious risk.

How can you be at a risk by sharing your internal state with an external entity?


When the Trainer asks you about your comfort level about a particular topic and you honestly tell him of the things that you don't know, he immediately comes to know where you stand.

Because you are in a training program it becomes mandatory for you to disclose these details. But be honest and think that if that wasn't the case, would you ever tell anyone of the things that you don't know.

To the outside world, we know everything. Am I right? At least I haven't come across anyone who publicly accepts the things that he doesn't know. Everyone wants to create an impression that they know everything.

Whenever you are sharing your current state with a Trainer, you are basically sharing something that is "Private". It is something that you wouldn't normally share with the outside world.

And when you share this internal or private information with the trainer and if he is not the right kind of person, he can misuse the information and can harm you in a big way. And that will become encapsulation violation.

I conduct a lot of training programs for different organizations. The moment I ask the participants for their introduction and the moment they share their level of knowledge with me, I can go around telling this to everyone and can harm their current job or their future job prospects.

The moment I come to know of the internal state which is private information, I can create a situation where in the participant's future is at stake.

Although I don't do any such thing, by giving you this example, I am just trying to show you a case where in you are forced to share your internal details with the outside world and for you to understand a practical case of encapsulation violation.

As I said that there are times when you are forced to share your internal details with the outside world and in such a case encapsulation will get violated.

Then in such a situation how do you safeguard yourself?

You must now be thinking that Training programs and trainers were never so dangerous.

Yes there is a problem of encapsulation violation. But there are always best practices to safeguard you from something like this.

Let's understand that if in this real world there is a situation where you are forced to share your internal details with the outside world, then there has to be a way by which you can safeguard yourself.

There is only one way out. There is only one way by which you can safeguard yourself. And that is if you are sharing your internal state with an external object that can be trusted.

If there is an encapsulation violation, you can still be safe if you have shared your internal details to an object which can be trusted.
What are the ways in which you can trust an external object?

There are two ways of trusting

  • Implicit Trust or Implicit way of trusting.


  • Explicit Trust or Explicit way of trusting.

An example of "Implicit Trust" or implicit way of trusting is your parents. They trust you implicitly. They do not ask for your credentials before they trust you. If there is something confidential within your family, your parents will implicitly trust you and share the same with you.

Can you think as to why your parents trust you implicitly?

Or

When can a system trust an external system implicitly?

The principle of implicit trust says that "whenever a system is in a situation wherein it is forced to share its internal state with an external object or to the outside world; it can implicitly trust only that external object which is created by him or can be created by him".

Your parents trust you implicitly because they know that you are an object created by them. Or my parents trust me because they know that I am an object created by them.

So I repeat that the principle of implicit trust says that "whenever a system is in a situation wherein it is forced to share its internal state with an external object, the system can safely share its details with that external object if that external object is created or can be created by that system".

And it is suggested to prefer "Implicit" trust over "Explicit" trust.

But let me tell you that many times there is a situation wherein you are forced to share your details with an external system which is neither created by you nor can be created by you.

A Trainer is a classical example for it.

Now given a situation where you are forced to share your internal details with an external object which is neither created by you nor can be created by you, how do you trust that external object?

Then the only option that you have is to "Explicitly" trust this external object on the basis of its public credentials.

Explicit trust works on the concept of credentials.

A "Trainer" is not a system that is created or can be created by a participant. In such a case if the participant has to ensure that he is not harmed in any way by sharing his internal details, he has to explicitly trust the trainer.

How does explicit trust work in the case of a training program?

Think again as to how training programs start.

If you think carefully, a training program always starts with the Trainer introducing himself first.

The Trainer will always introduce himself first. And while he is doing so, he will first talk about his "Name", and then talk about himself. He will tell you about his experience, what he has done in the past, what he is doing currently and what he intends doing in future.

Whenever I start my training programs I do a lot of boasting about myself. And I tell my participants that please don't mind this as it is a technical thing that I am supposed to do.

When I was speaking about myself, what was I trying to do?

I was basically trying to give you my public credentials.

One very important thing that we need to discuss is as to who is responsible for encapsulation violation?

Encapsulation violation is a serious offence because the target system is at the risk of losing its existence in the system. But if at all it does happen, who is responsible for it?

Let me give you the same example.

When I went to Ramesh, he started flashing his internal state. He started flashing the implementation of his behaviour. I went to him, I came to know about his internal details and I harmed him in a big way.

Now Ramesh comes to me and says that, "Hemant why did you do this to me"?

To which my most obvious answer was, "Why did you show it to me"?

So who is responsible for encapsulation violation?
 
Very simply, it is the object or the system itself which is responsible for encapsulation violation.

If Ramesh would have safeguarded himself or if he wouldn't have flashed his internal details or the implementation of his behaviour, there was no way I could have harmed him.

 

So remember that it is always the system itself that is responsible for encapsulation violation. You cannot blame anyone else for it.

In the context of my training program, if I was not a right person and I harmed you after knowing your internal details. In that case if you come and ask me, "Hemant why did you do it"? I will reply "Why did you show it"?

In a situation like this, you can neither avoid sharing the details nor blame anyone as you yourself were responsible for encapsulation violation. If you don't share the details, there is no way that I can make a change on you. And the moment you share your internal details with me, there is a risk that I can harm you.

Therefore the only way of solving this problem is to trust me as a trainer.

Can the participant trust me implicitly?

Am I created by the participant or can be created by the participant?

So the only option left for the participant is to trust me explicitly

And how do you do that? How do you trust the trainer explicitly?

Like I said it all starts with the trainer introducing himself first. And while doing so the trainer is supposed to give out all his public credentials.

In my Training programs, this is how I go about doing it.

Once I have broadcasted all my public credentials, I visit the first participant in the chain and I ask him, "do you accept me as a trainer"?

Based on my public credentials, I give him a chance to decide whether he trusts me as a trainer. He is given a chance to decide whether Hemant can be a trusted entity.

If the participant thinks that Hemant is a trusted entity, he has the credentials to make the changes on him, he then passes on his internal state to me.

And once I know his internal state, I am in a position to make changes on him.

I then visit the nest element in the chain. I go to the next participant and ask him if he accepts me as a trainer. Again he is given a chance to decide whether he trusts me as an external entity. If he feels that Hemant as an external entity can be trusted, he hands over his internal details to me and that is how I make the changes on him.

I then visit the next participant in the chain. Again I call the "accept" method on him, passing on my credentials as an argument and the participant is given a chance to decide whether he can trust me or not. And if he feels that Hemant as an external entity can be trusted, the basically hands over his internal state to me and I make the desired change on him.

I keep doing this and that's how I basically add behaviours to the participants. It is very difficult for people to understand as to why this "Accept" method is needed or why this protocol of "Accepting" needed.

This protocol of "Accepting" is needed to enable something called as explicit trust.

Sometimes, in training programs, if it is a project based training or Project specific training, all the participants are nearly of the same state. But still I visit each one of them.

Many times participants think that I am wasting their time. They think that when all of us have the same state, then why he is wasting time.

Let me tell you that in spite of knowing that the participant's have the same state, what I was doing was I was giving them a chance to decide whether they would want to trust me or not.

If I had not given you the opportunity or if the trainer had not given you the opportunity, and if the trainer would have harmed you, in that case you could have sued your company, or the training manager or even the trainer for that matter.

But once I have given you the opportunity to decide whether you want to share your internal state with me or not, you cannot do anything. Because now if you come and say that Hemant why did you do it to me, my answer would be why did you show it to me.

This is how explicit trust is used in the corresponding system to ensure that encapsulation doesn't get violated.

The training program is a classical example of Visitor Design Pattern where in Explicit trust is being used to solve the problem of encapsulation.

There are 3 design patterns which exclusively deal with encapsulation violation.

  • Visitor Design Pattern dealing with explicit trust.


  • Iterator Design Pattern dealing with implicit trust.


  • Memento Design Pattern dealing with implicit trust.


In your computer systems where exactly do you see the concept of explicit trust being used?

Let's say that using your browser you are trying to access a web page which has some executable programs within the same, dynamic programs like DLL or applet etc.

If your webpage has DLL or some applet within it, what is the browser supposed to do?

According to me the browser is supposed to give you a "Ping". It is supposed to give you an alert saying that there is an executable program in this page, do you want to allow the executable program to access your file system.

Would you allow any executable program to access your file system?

Never take the risk. If you allow an executable program to access your file system, what you are doing is you are basically exposing your internal structure or internal state to that corresponding executable program. And if it is a malicious program, it can harm your system.

This is encapsulation violation. There is an external entity who is trying to look into your internal structure and state and if at any point of time you allow the same to happen, then you are in a big risk.

Why did your browser give you a "Ping"?

Please understand that this executable program is meant for some behaviour. It is meant for adding some value to you. Now the issue is; for this executable program to add value to you, it needs to access your internal file system.

Now, if you say that you don't want this executable program to look into your internal file system, then it basically cannot add any value to you.

And if you allow this executable program to access your file system, everything that happens thereafter is your responsibility.

Can you implicitly trust this executable program?

Is this program created by you or can be created by you?

No. You cannot implicitly trust this program because none of the above is true.

This is why the browser gives you an alert saying that there is an executable program in this page. Do you want to accept this executable program?

You have 2 options. Either Yes or No.

If you say No, you will not get that behaviour.

If you say yes, everything that happens thereafter is your responsibility. Here explicit trust is being used.

How does the executable program give you its credentials?

One way is to boast like me. I know this and I know that. But what is the guarantee that whatever I am saying is right? Same thing applies over here. This executable program can boast that it is a right program and a non-malicious program. But what is the guarantee?

There are certain agencies in the world that are in the business of providing certificates. They basically check the program and the way it is written to ensure that there is no malicious content.

You would have noticed during the alert that comes, there is something called as "view certificates". Ideally when the alert comes to you, you are actually supposed to view the certificates so that you can take a call as to whether you want to trust the corresponding program or not. The moment you say yes, whatever happens after that is your responsibility.

This is a classical case where you can see explicit trust in your computer systems.

Encapsulation as a concept or encapsulation violation and its corresponding rules may not be appreciated at a programming level. These are much more valid at a system level.

There is a definite reason behind the same. If you see the way software has developed over a period of time, you will see that it all started with small departments of the organization coming out with their own software to basically automate certain aspects of the organization. It all started with small little software being built.

Some 5-6 years back people realised that there are too many small programs trying to automate different aspects of the organization. Now they have to inter operate with each other. That is where people thought about "Enterprise Integration Application". But still all the applications were internal to an organization. The applications used to trust implicitly. So even till this point, there was no problem.

But today when we talk about "Enterprise Integration Application", we talk about one system belonging to one business making a change on another system belonging to another business.

Think of a case where in one system belonging to a business is making a change on another system belonging to another business. Can you trust the other system implicitly?

No. You cannot do it. You cannot trust them implicitly. You have to have some explicit trust based mechanism to trust these systems. And that's where standards like web services etc have a support for explicit trust as a mechanism to handle the issue of encapsulation violation.

So as a designer you will see that encapsulation is a very serious aspect that you need to understand because most of the design patterns are influenced by the concept of encapsulation.

What is the importance of encapsulation to both the parties being involved in an association relationship?

As I have already said that if the target object is encapsulated, there is no way that anyone can look into the private aspect of this system. That's how its USP is intact. No one can harm this target object.

But what does the "Calling" object get in return if the "Target" object is highly encapsulated? If you think that the calling object is getting nothing if the target object is highly encapsulated, then let me tell you it becomes a selfish model. And a selfish model doesn't work in the real world.

Hence even the calling object should get something in return if the target object is highly encapsulated.

Can you think of what is that something that the calling object gets if the target system is highly encapsulated?

I will give you an example. Think about it.

Who is the owner of the state of an object?

According to me, it is the object itself. When you say that the object is the owner of the state, it means that the object is free to change its state without notifying the outside world.

Let's say that Ramesh was accidently flashing his internal state. Now because he was flashing his internal state, I start programming to his internal state. And since he is the owner of his state he is free to change his state any time without notifying me. And because I am directly programming myself to his internal state, every time his internal state changes, I am supposed to change myself. Something I do not want to happen.

Similarly who is the owner of implementation of behaviour?

As you know it is the object who is the owner of the implementation of the behaviour. And that is why it is free to change its implementation at run time without notifying the outside world.

Let's say that Ramesh was accidently flashing the implementation of behaviour and I start programming to that corresponding behaviour. Every time Ramesh changes the implementation of the behaviour, I am getting impacted because I am programming myself to the implementation of that behaviour. And this is something I do not want to happen.

So let me tell you that encapsulation is beneficial to both the parties. For the target object, his USP remains intact and at no time anyone can harm him. For the calling object, no way he can program himself to the variable aspects of the target object where in any changes happening on the other side could have forced it to change.

Hence encapsulation is beneficial to both the parties involved in the association relationship.

There is one more reason why encapsulation is needed. There is one more perspective to it.

We know that any well designed system should be a Black Box to the user. What is the concept of Black box all about? Don't you think it is encapsulation?

The moment we started discussing about systems, we said that from a user's perspective, any well designed system is nothing but a Black Box which offers a set of behaviours to the outside world. The only thing that the user uses is the behaviour. Are we not talking about encapsulation?

So whenever we are talking about encapsulation, all the issues like structural flexibility, behavioural flexibility come into picture.

For example, when you are watching TV, it should never show its internal structure or the implementation of the behaviour to you. If it shows you all these details, then its encapsulation gets violated.

If you are still not convinced about encapsulation, I shall give you one more and a final example. We keep doing this left and right. Otherwise association would not be possible.

You must have come across Marriage counsellors giving advice to couples in a relationship, where in they say that for any relationship to succeed there should be enough space given to each other.

What do you understand by "Space" in a relationship?

Let me give you an example. As youngsters you all would be able to relate to it and understand it much better. But please take it in the right sense.

Let me talk about my association relationship with my girlfriend. My association relationship with my girlfriend will last only till the time I don't get into her private life. And her association relationship with me will succeed only till the time she doesn't get into my private life. The moment any of us try getting into the private life of each other, both of us will feel threatened and immediately the association relationship will die.

Whenever there is an association relationship between two human beings, there is something called as the "Public face" of the relationship and "Private aspect" of the relationship.

My association relationship will succeed only till the time I don't get into her private life. The moment I try to do this, she will get threatened and the association relationship will die. The same is the case with me.

Never get into the private aspect of the other entity. This is called the space in a relationship and that's nothing but encapsulation being used here.

If association relationships succeed in the world, it's only because of encapsulation.

Encapsulation is a prerequisite for any association relationship. Be it between man-to-man, man-to-machine, machine-to-machine, organization-to-organization. It is always true.

Let me give you an example of me and my TV. I am being provided with a Remote Control or a user interface to change the channels or for any other functionality. Still if I go and open the TV from behind, put my hand inside and try to change the channel, what will happen?

I will get a Shock.

Why?

I will get a shock because I was trying to violate the encapsulation of the TV.

Let's say you and I own two different organizations. I have outsourced some work to your organization. One fine day I come to your office and tell you that please get my work done by a particular developer Mr. X. You will at once say that please be concerned with your work getting done and not as to who is doing it.

Be it between any entities, if it is an association relationship, the entities should always restrict themselves to the public aspect of the relationship. Never try to get into the private aspect of the relationship. The moment you do that the target object will get threatened and the association relationship will die.


 
Hemant Jha
Founder - VPlanSolutions
Researcher, Trainer

www.VPlanSolutions.co.in