Object Oriented Concepts: Encapsulation

This Post deal with one of the fundamental concepts about Object Oriented which is called Encapsulation. If you want to aspire to a good Object Oriented Design that’s one of those “rules” to follow . The Encapsulation is an arguments to know if you want to overcome with success the Sun Certified Programmer for the Java Platform too. It’s contained in the Objective 5.1 of section 5.

* Develop code that implements tight encapsulation, loose coupling, and high cohesion in classes, and describe the benefits.

Starting with some code so you’ll understand better the meaning of Encaspulation. So we have created a very simple java class like below:

public class Car{
	public int speed;
	public int weight;
}

How you can see the Car class have two fields speed and weight both them are public. That’s means anyone can access and modify the fields of class in any way. To show that we have wrote the following java code:

public class MyTest{
	public void main(String[] args){
		Car car = new Car();
		car.speed=-20;
		car.weight=5;
	}
}

Now, consider the highlighted statements, how you can guess there are no controls on values of Car class fields. Often that’s a big problem. Using the Encapsulation it allows us to monitor and completely control the values that can be assigned to the class attributes.Then Encapsulation hides attributes by preventing, so access direct can take place only through specific methods. If all attributes are ecapsulated then we talk about Tight Encapsulation. Now adjust our class so that it meets the Encapsulation , the result will be the following:

public class Car{
	private int speed;
	private int weight;
	public void setSpeed(int value){
		if(value>100){
			this.speed=value;
		}else{
			this.speed=100;
		}
	}
	public int getSpeed(){
		return this.speed;
	}
	public void setWeight(int value){
	// todo - you can define a control for the value entered for Weight field
		this.weight=value;
	}
	public int getWeight(){
		return this.weight;
	}
}

How you can see, it’s very easy define a class that meets the Tight Encapsulation requirements. It’s enough to specify all fields of the class as private, and for each of these defining methods getter and setter that allow access to the specific field. The naming convention used is like JavaBeans, see below:

set<PropertyName>

get<PropetyName>

Note that the attributes must be strictly defined private and not protected. Using protected means to expose the attributes to derived classes and at the package level which will then have full control. So the access modifier protected should be used only if it’s really necessary.

The benefits of using Tight Encapsulation are considerable, not only in the case that you decide to perform validation checks on the fields of the class, but mostly because you can hide the implementation of the class making the code more flexible, feasible and extensible. If the attributes of a class are hidden then you can change the implementation without having to change all the classes that use them. The code wrote above can be modified without changing the class MyTest that uses it in the following manner:

public class Car{
	private String speed;
	private String weight;
	public void setSpeed(int value){
		if(value>100){
			this.speed=Integer.toString(value);
		}else{
			this.speed=&quot;100&quot;;
		}
	}
	public int getSpeed(){
		return Integer.parseInt(this.speed);
	}
	public void setWeight(int value){
		this.weight=Integer.toString(value);
	}
	public int getWeight(){
		return Integer.parseInt(this.weight);
	}
}

You may also notice that the Car class has been heavily modified but there are no impacts on other classes that use them. This Encapsulation feature is called Information Hiding. if you do not have a direct access (public or protected fields) to the class attributes it’s possible to modify the data type attribute without having to change the points where it is used via getter and setter method , but obviously you don’t have to change the signature of these methods. Another Encapsulation benefit is to make easier the decoupling with other classes, because what’s hidden can not be coupled.

It’s always advisable to use as much as possible the Encapsulation though initially not expected to do some checks to validate the attributes or write some specific logic in the getter and setter methods. All this can be done later reducing the problem of having to modify the code that uses our class.

That’s all :-)

Some Books About SCJP and Object Oriented:

1 comment so far ↓

#1 Giorgio Sironi on 09.02.09 at %I:%M %p

The next step is trying to delete getters and setters so that you can encapsulate also the list of fields and not only their implementation. For instance, providing method accelerate() and brake() without giving (at least writing) access to speed.

Leave a Comment