Why Encapsulation Is Fundamental to Object-Oriented Programming
From the book
Encapsulation is the fundamental concept of OO. Whenever the interface/implementation paradigm is covered, we are talking about encapsulation. The basic question is what in a class should be exposed and what should not be exposed. This encapsulation pertains equally to data and behavior. When talking about a class, the primary design decision revolves around encapsulating both the data and the behavior into a well-written class.
Stephen Gilbert and Bill McCarty define encapsulation as “the process of packaging your program, dividing each of its classes into two distinct parts: the interface and the implementation.” This is the message that has been presented over and over in this book.
But what does encapsulation have to do with inheritance, and how does it apply with regard to this chapter? This has to do with an OO paradox. Encapsulation is so fundamental to OO that it is one of OO design’s cardinal rules. Inheritance is also considered one of the three primary OO concepts. However, in one way, inheritance actually breaks encapsulation! How can this be? Is it possible that two of the three primary concepts of OO are incompatible with each other? Let’s explore this possibility.
How Inheritance Weakens Encapsulation
As already stated, encapsulation is the process of packaging classes into the public interface and the private implementation. In essence, a class hides everything that is not necessary for other classes to know about.
Peter Coad and Mark Mayfield make a case that when using inheritance, encapsulation is inherently weakened within a class hierarchy. They talk about a specific risk: Inheritance connotes strong encapsulation with other classes but weak encapsulation between a superclass and its subclasses.
The problem is that if you inherit an implementation from a superclass and then change that implementation, the change from the superclass ripples through the class hierarchy. This rippling effect potentially affects all the subclasses. At first, this might not seem like a major problem; however, as we have seen, a rippling effect such as this can cause unanticipated problems. For example, testing can become a nightmare. In Chapter 6, “Designing with Objects,” we talked about how encapsulation makes testing systems easier. In theory, if you create a class called Cabbie (see Figure 7.9) with the appropriate public interfaces, any change to the implementation of Cabbie should be transparent to all other classes. However, in any design, a change to a superclass is certainly not transparent to a subclass. Do you see the conundrum?
)
Figure 7.9. A UML diagram of the Cabbie class.
If the other classes were directly dependent on the implementation of the Cabbie class, testing would become more difficult, if not untenable.
Keep Testing
Even with encapsulation, you would still want to retest the classes that use Cabbie to verify that no problem has been introduced by the change.
If you then create a subclass of Cabbie called PartTimeCabbie, and PartTimeCabbie inherits the implementation from Cabbie, changing the implementation of Cabbie directly affects the PartTimeCabbie class.
For example, consider the UML diagram in Figure 7.10. PartTimeCabbie is a subclass of Cabbie. Thus, PartTimeCabbie inherits the public implementation of Cabbie, including the method giveDirections(). If the method giveDirections() is changed in Cabbie, it will have a direct impact on PartTimeCabbie and any other classes that might later be subclasses of Cabbie. In this subtle way, changes to the implementation of Cabbie are not necessarily encapsulated within the Cabbie class.
)
Figure 7.10. A UML diagram of the Cabbie/PartTimeCabbie classes.
To reduce the risk posed by this dilemma, it is important that you stick to the strict is-a condition when using inheritance. If the subclass were truly a specialization of the superclass, changes to the parent would likely affect the child in ways that are natural and expected. To illustrate, if a Circle class inherits implementation from a Shape class, and a change to the implementation of Shape breaks Circle, then Circle was not truly a Shape to begin with.
How can inheritance be used improperly? Consider a situation in which you want to create a window for the purposes of a graphical user interface (GUI). One impulse might be to create a window by making it a subclass of a rectangle class:
public class Rectangle {
}
public class Window extends Rectangle {
}
In reality, a GUI window is much, much more than a rectangle. It is not a specialized version of a rectangle, as is a square. A true window might contain a rectangle (in fact, many rectangles); however, it is not a true rectangle. In this approach, a Window class should not inherit from Rectangle, but it should contain Rectangle classes:
public class Window {
Rectangle menubar;
Rectangle statusbar;
Rectangle mainview;
}
A Detailed Example of Polymorphism
Many people consider polymorphism a cornerstone of OO design. Designing a class for the purpose of creating totally independent objects is what OO is all about. In a well-designed system, an object should be able to answer all the important questions about it. As a rule, an object should be responsible for itself. This independence is one of the primary mechanisms of code reuse.
As stated in Chapter 1, polymorphism literally means many shapes. When a message is sent to an object, the object must have a method defined to respond to that message. In an inheritance hierarchy, all subclasses inherit the interfaces from their superclass. However, because each subclass is a separate entity, each might require a separate response to the same message.
To review the example in Chapter 1, consider a class called Shape. This class has a behavior called Draw. However, when you tell somebody to draw a shape, the first question is likely to be, “What shape?” Simply telling a person to draw a shape is too abstract (in fact, the Draw method in Shape contains no implementation). You must specify which shape you mean. To do this, you provide the actual implementation in Circle and other subclasses. Even though Shape has a Draw method, Circle overrides this method and provides its own Draw method. Overriding basically means replacing an implementation of a parent with your own.
Object Responsibility
Let’s revisit the Shape example from Chapter 1 (see Figure 7.11).
)
Figure 7.11. The Shape class hierarchy.
Polymorphism is one of the most elegant uses of inheritance. Remember that a Shape cannot be instantiated. It is an abstract class because it has an abstract method, getArea(). Chapter 8 explains abstract classes in great detail.
However, Rectangle and Circle can be instantiated because they are concrete classes. Although Rectangle and Circle are both shapes, they have some differences. As shapes, their area can be calculated. Yet the formula to calculate the area is different for each. Thus, the area formulas cannot be placed in the Shape class.
This is where polymorphism comes in. The premise of polymorphism is that you can send messages to various objects, and they will respond according to their object’s type. For example, if you send the message getArea() to a Circle class, you will invoke a different calculation than if you send the same getArea() message to a Rectangle class. This is because both Circle and Rectangle are responsible for themselves. If you ask Circle to return its area, it knows how to do this. If you want a circle to draw itself, it can do this as well. A Shape object could not do this even if it could be instantiated because it does not have enough information about itself. Notice that in the UML diagram (Figure 7.11), the getArea() method in the Shape class is italicized. This designates that the method is abstract.
As a very simple example, imagine that there are four classes: the abstract class Shape, and concrete classes Circle, Rectangle, and Star. Here is the code:
public abstract class Shape{
public abstract void draw();
}
public class Circle extends Shape{
public void draw() {
System.out.println("I am drawing a Circle");
}
}
public class Rectangle extends Shape{
public void draw() {
System.out.println("I am drawing a Rectangle");
}
}
public class Star extends Shape{
public void draw() {
System.out.println("I am drawing a Star");
}
}
Notice that only one method exists for each class: draw(). Here is the important point regarding polymorphism and an object being responsible for itself: The concrete classes themselves have responsibility for the drawing function. The Shape class does not provide the code for drawing; the Circle, Rectangle, and Star classes do this for themselves. Here is some code to prove it:
public class TestShape {
public static void main(String args[]) {
Circle circle = new Circle();
Rectangle rectangle = new Rectangle();
Star star = new Star();
circle.draw();
rectangle.draw();
star.draw();
}
}
The test application TestShape creates three classes: Circle, Rectangle, and Star. To draw these classes, TestShape asks the individual classes to draw themselves:
circle.draw(); rectangle.draw(); star.draw();
When you execute TestShape, you get the following results:
C:\>java TestShape I am drawing a Circle I am drawing a Rectangle I am drawing a Star
This is polymorphism at work. What would happen if you wanted to create a new shape, such as Triangle? Simply write the class, compile it, test it, and use it. The base class Shape does not have to change—nor does any other code:
public class Triangle extends Shape{
public void draw() {
System.out.println("I am drawing a Triangle");
}
}
A message can now be sent to Triangle. And even though Shape does not know how to draw a triangle, the Triangle class does:
public class TestShape {
public static void main(String args[]) {
Circle circle = new Circle();
Rectangle rectangle = new Rectangle();
Star star = new Star();
Triangle triangle = new Triangle ();
circle.draw();
rectangle.draw();
star.draw();
triangle.draw();
}
}
C:\>java TestShape
I am drawing a Circle
I am drawing a Rectangle
I am drawing a Star
I am drawing a Triangle
To see the real power of polymorphism, you can pass the shape to a method that has absolutely no idea what shape is coming. Take a look at the following code, which includes the specific shapes as parameters:
public class TestShape {
public static void main(String args[]) {
Circle circle = new Circle();
Rectangle rectangle = new Rectangle();
Star star = new Star();
drawMe(circle);
drawMe(rectangle);
drawMe(star);
}
static void drawMe(Shape s) {
s.draw();
}
}
In this case, the Shape object can be passed to the method drawMe(), and the drawMe() method can handle any valid Shape—even one you add later. You can run this version of TestShape just like the previous one.
Abstract Classes, Virtual Methods, and Protocols
Abstract classes, as they are defined in Java, can be directly implemented in .NET and C++ as well. Not surprisingly, the C# .NET code looks similar to the Java code, as shown in the following:
public abstract class Shape
{
public abstract void draw();
}
The Visual Basic .NET code is written like this:
Public MustInherit Class Shape
Public MustOverride Function draw()
End Class
The same functionality can be provided in C++ using virtual methods with the following code:
class Shape
{
public:
virtual void draw() = 0;
}
As mentioned in previous chapters, Objective-C does not fully implement the functionality of abstract classes.
For example, consider the following Java interface code for the Shape class we have seen many times:
public abstract class Shape{
public abstract void draw();
}
The corresponding Objective-C protocol is shown in the following code. Note that in both the Java code and the Objective-C code, there is no implementation for the draw () method:
@protocol Shape @required - (void) draw; @end // Shape
At this point, the functionality for the abstract class and the protocol are pretty much equivalent; however, here is where the Java-type interface and the Objective-C protocol diverge. Consider the following Java code:
public abstract class Shape{
public abstract void draw();
public void print() {
System.out.println("I am printing");
};
}
In the preceding Java code, the print () method provides code that can be inherited by a subclass. Although this is also the case with C# .NET, VB .NET, and C++, the same cannot be said for an Objective-C protocol, which would look like this:
@protocol Shape @required - (void) draw; - (void) print; @end // Shape
In this protocol, the print () method signature is provided, and thus must be implemented by a subclass; however, no code can be included. In short, subclasses cannot directly inherit any code from a protocol. Thus, the protocol cannot be used in the same way as an abstract class, and this has implications when designing an object model.