Encapsulation : why?

Now, I remember, I had this question when developing my first framework. At some point in time, when developing your own framework of some kind, you must be asking the same question. The question is “Why I will make properties of a class private?! When everyone is capable of accessing it, why properties would be private ?”
This reminds me of my first dive into the object oriented programming in Java. All most all the books, explained that, all the properties of an object should be private with its getters and setters as public. I asked myself, it does not make any sense to write some more lines of code for the same thing. If at all, user needs to access my properties, I can make them public at the first place.
The answer was not clear at that point in time. But as I went along and developed some couple of more frameworks for my projects, the encapsulation part slowly made sense to me.
Encapsulation is not data hiding. Yes, you heard it right. Its not hiding the data. Its bundling the data with some methods to regulate the process, how those data can be manipulated.
Lets take an example, Ball is an object, which has to be moved across the stage. Well, in that case, we can write a Ball class and use it to move by changing the x and y position of it. Thats straight enough. Now, if there is a requirement that the Ball must be moved in straight line from left to right, then what happens. We comeback to our main file, or the stage file, or wherever we have used our Ball object to move. change the code and we are done. Impressive! In the process actually we are modifying something else, not the Ball Object. Though the requirement for Ball has changed, because of our way of coding, we have to modify some other class so as to fix the problem. There comes the solution of encapsulation. What if all the movement code are there with the Ball class. In order to move it, let there be a method named “moveIt()”

public function moveIt():void
{
//Do code for moving the ball from left to right
}

Now, all we need to do is, hide the ball movement code inside our Ball object. The calling object will just call the method named “moveIt()” of the ball object. Incase there is a requirement change, and now the Ball should move from right to left, there would be no worries as to where and how to change the code. The only thing which will change is the implementation of the moving ball code inside the “moveIt()” method. There may be a direction property of ball object, which will check the direction of movement of the ball. That also could be implemented inside the “moveIt()” method as below.

public function moveIt():void
{
//if the ball is moving from leftToRight
this.direction=”leftToRight”;
//Do code for moving the ball from left to right
if(this.x>=MaxWidth)//ball reaches the rightmost point
{
this.direction=””;//no direction now, as ball is stopped moving
// stop the ball
}
}

Similarly if requirement is to move it from right to left, the code will look as below

public function moveIt():void
{
//if the ball is moving from right To left
this.direction=”rightToLeft”;
//Do code for moving the ball from right to left
if(this.x<=0)//ball reaches the leftmost point
{
this.direction=””;//no direction now, as ball is stopped moving
// stop the ball
}
}

Now we can see that the private property “direction” can not be accessible from outside. but its only used inside the Ball object. So the data is encapsulated. We can still interact with it but not directly. The rules could be set as to how to interact through the public exposed methods.

Another example would be, suppose we have a property of an object, which is always a multiple of 2. But then we do not want our user to know that the property is always a multiple of 2. So we may expose the setter method as to take any integer, but internally we will be storing that as a multiple of 2. The code would be something like below

private var _myNum:int;
public function get myNum():int { return this._myNum; }
public function set myNum(value:int):void
{
this._myNum = 2*value;// we are not storing the user value directly
}

Now it makes a lot of sense to have all the properties as private. Only expose those with setters, which are really needed to be exposed. Another advantage is, any requirement change will just make us change at one place (if the value should be multiple of 3 instead of 2, we just change the setter).

Happy Flashing 🙂

Advertisements

Author: saumya

designer / developer / maker / educator @saumya

10 thoughts on “Encapsulation : why?”

  1. Well first things first, I personally don’t even use “private” find it more of a hurdle then of any real use. I pretty much use “protected” for everything, don’t really see the need to hide stuff when you want to extend the framework. But anyways about Encapsulation thingy… Hm, with the whole getter and setter stuff I only use them when I know when a property is going to be set it will be doing more then just setting/getting a simple value. Lots of situations where id only want the user to set or get something, never both on the same thing. I try and black box a lot of stuff when I build a framework, that way i don’t have to deal with all the nitty gritty.

    1. Well, agreed. Protected is a better option and the way one black boxes (encapsulates) is a preference and personal choice and of-course project requirement. In that case, one may encapsulate the whole part of a small engine from the whole framework. But again, in the end one has to expose some public method to get access to the engine from the application.
      The setters are generally not setters only, they do some kind of other things with it. Thats rightly said. But while beginning the development process, if we expose the properties with public, later it will be difficult to add some more logic to the setter of it. In the beginning only if it is private with a public setter, as a developer one has the control of things.
      And finally yes, in simpler terms, whole concept of black boxing is known as encapsulation.

  2. Generally I don’t use encapsulation myself, but right now, I only work on projects by myself; so I have a fair idea of what’s going on where.
    But I feel encapsulation is a requirement when there’s more than just one person working on the project. Having clear boundaries on what classes can and can’t do and making sure that all the coders follow the same rules will make it a bit harder, but much easier than trying to follow the code because someone hasn’t done it right.

    1. Thats spot on about the requirement of encapsulation is more in a team environment. Well, in a personal project also, if we are developing a framework for others to use, the need comes in. This is upto how much access one need to give the user to internals of a framework.

  3. thanks saumya, this article really helps to understand the actual concept of data hiding, i was using it since few years but not aware of exact application this article really helped me

  4. We’re a group of volunteers and starting a new scheme in our community. Your website provided us with valuable information to work on. You’ve done an impressive job and our whole community will be thankful to you.

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