5 Pillars Of OO: Part 2 Encapsulation

Encapsulation is the ability to conceal the object's members behaviour and features. For example, carrying on from the previous blog, the Cat's class speed and name can't be access directly from any instance.

Instead, the fundamentals of OO insist that these members can only be accessed through public methods. And here we come to the meaning of Access Modifiers. Look at the following code as an example to explain what access modifiers really are;


private String last_name;
public  String first_name;
protected String middle_name;

In java, there are four access modifiers, and yes I have only displayed three, but hold on to your horses.

  • Private: Only the class can contain it. 99% of all fields are private.
  • protected: Allows the member to be accessed by any class in the package, but not in other packages. Can be useful if you want a final member and the name is also used in other packages.
  • Public: Everything and anything theoretically can access it, not a good idea except in unique cases such as when used with the keyword final, which means it can not change.
  • No Accessor: this type of members can be accessed by all classes in the packaged and any other package within the same project. dangerous as much as its sibling Public.

For a little bit more info head to the Java Docs.


So that we are clear on access modifiers, why are they useful? I'd say, good question my friend.

You don't want people like me changing the status of your class members. Programmers should always protect themselves from other developers.... This also gives you a way to control and do checks on the input before changing your field.

For example, in loosely written languages, you'd have to check for types, but that's not an issue for java. But you'd want to check for other million reasons. Assume that you have a class which represent an Adult person which inherits the person class.



package com.people.adults

public class Adult extends Person
{
	private int age;

	public Adult(int age)
	{
	}
    
	public Adult(int age)
	{
		this.setAge(age);
	}
	
	//Adults have to be of age 
	public void setAge(int age)
	{
                (age <= 17 || age > 100 )? this.age=0:this.age=age;
	}
    
    //Check if it is a senior adult
    public boolean isSenior()
    {
    		if (age >  50)
		{
			return true;
		}else
		{ //Too young or senior !! 
			return false; 
		}
    }

}

In this scenario, it is hard to imagine other programmers abusing your code. For instance, if I have access to your public package, and wanted to extend or use your adult class, I'll have no means of changing its status without going through checks and guards you have put up and those which are already protecting your code by simply fooling the OO way!

Example;


package com.people.me
import com.people.adults
public class main {

    public void main(int[] args) {
        Adults anAdult = new Adults();
        //Test 1 will fail; 
        //because we used Encapsulation correctly & protected our code against outsiders
        anAdult.age = 14; //can not access members directly

        //Test 2 will fail; 
        //again because you set concerte definition of what it means to be an adult
        anAdult.setAge(13);

        //Final test will pass
        //because it followed the rules of modifiers & the logic you put at hand
        anAdult.setAge(24);
    }

}



Summery


Think of encapsulation as a firewall against potential users of your code, yourself included. Not just a simple firewall, but a tool which allows you to shape the definition of your class. In essence, it's the mechanism that is equivariant of defining the embodiment of a real object.

Stay tune for the next Pillar.

comments powered by Disqus