An extremely important and useful concept is that of encapsulation; it has direct impact on
cohesion, decoupling, integrity, reusability and results in better readable and maintainable code. Exactly what is it, why do you need it and how can you achieve this? Read this three-part article series.
Encapsulation basically means nothing more than restricting access to a class's methods and properties. The power however lies in the intention:
With encapsulation, your are restricting access for a certain class so it becomes self-reliant and independent
That means it is better maintainable because it has
fewer dependencies that it relies on, and retains integrity because other classes can't just modify its properties, its 'state', because it is
self-reliant.
A basic example is where you make properties private and possibly write once (through constructor) and add only a getter method to make it read only.
Basic Example:
ActionScript Code:
class Apple {
public var type: String;
}
var apple:Apple = new Apple();
apple.type = "Breaburn";
trace(apple.type);
Encapsulated version:
ActionScript Code:
class Apple {
private var type: String;
public function Apple(type:String) {
this.type = type;
}
public function getType():String {
return type;
}
}
var apple:Apple = new Apple("Breaburn");
trace(apple.getType());
So In this example you go from a visible write-for-all property to a read-only write-once property. We've just encapsulated the type property. and because with that property all properties are encapsulated, we can say the class Apple is properly encapsulated.
Defining this phenomenon further, we can say that we've effectively hidden the implementation behind an interface, which is comprised of accessible methods, for example
public or
protected methods. This means that any object calling one of those methods doesn't know or need to know what happens
inside that method, the implementation. For example, a basket class doesn't need to know how an apple got its type or how the type is stored or determined; it only needs to know that it can retrieve it using the
getType() method. This among previously mentioned aspects is a strong reason why encapsulation makes for
better maintainable code; With the added flexibility, the Apple class can easily change how it gets its type and how it is determined lateron in the getType method and classes using the method
getType() won't ever break. The getType method might even call a bunch of other methods to form a type, or randomly return one.
so there you go, basic encapsulation in a nutshell.
Next time, we'll cover what it means to encapsulate behavior: to encapsulate what varies.
------
Here's a personal experience that I recall from my job.
Some guy made this Java class with public properties (non-encapsulated!) and when we encapsulated them, we got no compile errors. No problem we thought, everything honkydory. We didn't know however that there were JSP's that actually accessed them directly, and those references weren't checked by the compiler. Needless to say we found out about this when we went live and a page was reported dead (a runtime exception actually occurred). Too bad the guy that originally wrote it wrote it 6 years ago and was long gone, or we could make him get us coffee for the entire week.
------
