Section 3.5. The Three Pillars of Object-Oriented Programming

3.5 The Three Pillars of Object-Oriented Programming

Object-oriented programming is built on three sturdy pillars: encapsulation , specialization , and polymorphism .

Each class should be fully encapsulated, that is, it should fully define the state and responsibilities of that type. For example, if you create an Employee object, that Employee object should fully define all there is to know, from the perspective of your program, about each Employee. You do not, typically, want to have one class that defines the Employee's work information and a second, unrelated class that defines the Employee's contact information. Instead, you want to encapsulate all this information inside the Employee class, perhaps by aggregating the contact information as a member of the Employee class.

Specialization allows you to establish hierarchical relationships among your classes. For example, you can define a Manager to be a specialized type of an Employee and an Employee to be a specialized type of Person. This allows you to leverage the state and abilities of an Employee object in the more specialized form of the Manager.

Polymorphism allows you to treat a group of objects in a similar way and have the objects sort out how to implement the programming instructions. For instance, suppose you have a collection of Employee objects, and you want to tell each Employee to give himself a raise. Employees get a straight 5% raise, while raises for Managers are determined by how well they've fulfilled their annual objectives. With polymorphism, you can tell each object in the collection to give itself a raise, and the "right thing happens" regardless of the real type of the object. That is, each employee gets 5%, while each manager gets the appropriate raise based on objectives.

3.6 Encapsulation

The first pillar of object-oriented programming is encapsulation. The idea behind encapsulation is that you want to keep each type or class discreet and self-contained, so you can change the implementation of one class without affecting any other class.

A class that provides a method that other classes can use is called a server . A class that uses that method is called a client . Encapsulation allows you to change the details of how a server does its work without breaking anything in the implementation of the client.

This is accomplished by drawing a bright and shining line between the public interface of a class and its private implementation . The public interface is a contract issued by your class that says, "I promise to be able to do this work." Specifically, you'll see that a public interface says, "call this method, with these parameters, and I'll do this work, and return this value." A client can rely on a public interface not to change. If the public interface does change, then the client must be recompiled and perhaps redesigned.

On the other hand, the private implementation is, as its name implies, private to the server. The designer of the server class is free to change how it does the work promised in the public interface, so long as it continues to fulfill the terms of its implicit contract: it must take the given parameters, do the promised work, and return the promised value.

For example, you might have a public method that promises as follows : "Give me a dollar amount and a number of years, and I'll return the net present value." How you compute that amount is your business; if a client supplies a dollar amount and a number of years , you must return the net present value. You might implement that initially by keeping a table of values. You might change that at a later time to compute the value using the appropriate algebra. That is your business, and it does not affect the client. As long as you don't change the public interface (i.e., as long as you don't change the number or type of parameters expected or change the type of the return value) your clients will not break while you change the implementation.

Flylib.com

Category list

Similar pages

Section 3.5. The Three Pillars of Object-Oriented Programming

3.5 The Three Pillars of Object-Oriented Programming

3.6 Encapsulation

Similar products

Similar products