The purpose of encapsulation is to separate the specification of an object from its implementation. This separation allows you to use an object without knowing how it is implemented. Because the implementation is hidden, you have the freedom to apply new techniques and technologies to improve the implementation without corrupting the object's purpose and without affecting the other objects that collaborate with it. Unfortunately, we tend to think of objects only as instances of classes in the literal syntax of programming languages. But encapsulation applies to objects at every level of abstraction.
An object in the most basic sense is simply an entity. For an analyst, an object could be a unique physical entity, an aggregation of objects, a component, an application, a job, a system, or even a department or a company. Encapsulation is essential at all levels of abstraction in both software and user domains.
The following slide show contains several examples of objects.
Encapsulation reveals Opportunities
When applied consistently to the analysis process, encapsulation often reveals opportunities to redesign not just the software but also the problem domain practices and organization. This opportunity addresses one of the reasons that companies have not received the benefits of object-oriented methods, that is, the fact that the systems development process is not closely linked to the business reengineering process. In fact, you will see in the following lessons that refactoring applies equally well to organizational systems and software systems.