Encapsulation

By | May 16, 2014

In object-oriented programming, encapsulation is the inclusion within a program object of all the resources need for the object to function – basically, the methods and the data. The object is said to “publish its interfaces.” Other objects adhere to these interfaces to use the object without having to be concerned with how the object accomplishes it. The idea is “don’t tell me how you do it; just do it.” An object can be thought of as a self-contained atom. The object interface consists of public methods and instantiated data.

What is Encapsulation? The Free On-line Dictionary of Computing (http://www.instantweb.com/foldoc/) defines encapsulation as: The ability to provide users with a well-defined interface to a set of functions in a way which hides their internal workings. In object-oriented programming, the technique of keeping together data structures and the methods (procedures) which act on them. Well encapsulated objects act as a “black box” for other parts of the program which interact with it. They provide a service, but the calling objects do not need to know the details how the service is accomplished. In electronics, a resistor is an example of a well encapsulated object. It provides a particular service (so many Ohms of resistance) and you can plug it into a circuit and get the expected behavior. You don’t need to know how the resistance is accomplished, you just depend on the resistor to do its job. If you later decide to replace this resistor with one of another value, or by another manufacturer, you don’t have to rewire the circuit — you just pop the old resistor out and plug in a new one. If you chose the right component, the light bulb lights, and the buzzer sounds. Of course, if you choose wrong, you burn your entire house to the ground and nullify your homeowners insurance. A well encapsulated software object works the same way (without the house burning part). Let’s say you have an object representing an employee. Other objects might ask the employee for his name, his age, his salary and so forth. We call any object that interacts with your object a client of your object. A server is an object which provides any service. A client is an object which interacts with a server. For example, if your object represents an employee, it may be a server to the pension plan object, providing the pension plan with the employee’s social security number, age and income. Note that it may also be a client of that very same pension plan, asking the plan to act as a server and provide benefits. The employee is responsible for a set of activities. Some time after the program is up and running, you decide to rewrite your employee object to change the way it interacts with the database. If your employee object is well encapsulated, you can modify its internal structure without breaking any of the clients with which it interacts. The essential goal in encapsulation is to build self-contained modules that can be plugged into and out of other modules cleanly and without “side effects.”

Why is encapsulation important? Encapsulation is critical to building large complex software which can be maintained and extended. Many studies have shown that the greatest cost in software is not the initial development, but the thousands of hours spent in maintaining the software. Well encapsulated components are far easier to maintain. Once software is in place, another great expense is extending its functionality. As you add new features, there is risk that you’ll break existing parts of the application. Again, encapsulation helps to minimize this risk. In a well designed program, each object should have a single area of responsibility. That object presents an interface which defines the services the object provides. An interface is a contract your object makes with all its clients. Your object promises to provide certain services and to provide certain information. You, as author of this object, publish an interface and say, in essence, “Here is how you interact with my object. If you make these function calls, I promise to provide valid information in this format or to take these actions.” Note that a single object can offer more than one interface C++ does not support the concept of multiple interfaces (though Java does). You can create them in C++, however, by using abstract base classes to define various interface classes and then combine them using multiple inheritance or containment; this is how Microsoft’s COM classes work. It is common for an object to offer interfaces based on the privileges of the client class. For example, one client might be allowed only a subset of the possible operations on your new object. In addition, an object might offer a second interface to accommodate updates and changes to the object without breaking old client code. That is, older clients use the old interface, but newer clients can use the newer and updated interface.

Encapsulation is not information hiding The principles of information hiding go beyond the Java language facility for encapsulation By Wm. Paul Rogers, JavaWorld.com Words are slippery. Like Humpty Dumpty proclaimed in Lewis Carroll’s Through the Looking Glass, “When I use a word, it means just what I choose it to mean — neither more nor less.” Certainly the common usage of the words encapsulation and information hiding seems to follow that logic. Authors rarely distinguish between the two and often directly claim they are the same. Does that make it so? Not for me. Were it simply a matter of words, I wouldn’t write another word on the matter. But there are two distinct concepts behind these terms, concepts engendered separately and best understood separately. Encapsulation refers to the bundling of data with the methods that operate on that data. Often that definition is misconstrued to mean that the data is somehow hidden. In Java, you can have encapsulated data that is not hidden at all. However, hiding data is not the full extent of information hiding. David Parnas first introduced the concept of information hiding around 1972. He argued that the primary criteria for system modularization should concern the hiding of critical design decisions. He stressed hiding “difficult design decisions or design decisions which are likely to change.” Hiding information in that manner isolates clients from requiring intimate knowledge of the design to use a module, and from the effects of changing those decisions. Continue here

Leave a Reply