Encapsulation Information Hiding

1. Introduction: Object modeling plays a pivotal role in software design, aiming to create a blueprint for software systems by emphasizing real-world objects and their interactions. A crucial aspect of object quality assessment lies in two key concepts: cohesion and coupling. Both are vital to ensure maintainability, reusability, and scalability in object-oriented systems.
2. Cohesion refers to the degree to which the elements inside a module, class, or object are related to one another. A highly cohesive object has a well-defined, single responsibility and performs a specific task.

2.1. Evaluating Cohesion

To assess cohesion, consider the following criteria:

1. Single Responsibility: Does the object serve a single purpose? If an object has more than one responsibility, it may be beneficial to break it into multiple objects.
2. Functionality: Are all the methods and properties of the object related? Unrelated methods and properties can indicate low cohesion.
3. Reusability: Is the object generic enough to be reused in different contexts without modification? High cohesion often correlates with reusability.
4. Independence: Can the object function independently without excessively relying on other objects? If so, it's a sign of high cohesion.

3. Coupling:
   Coupling denotes the degree to which one object depends on other objects. Lower coupling indicates that an object is independent and doesn't rely heavily on others, leading to a system that's easier to maintain and evolve.
   3.1. Evaluating Coupling
   To assess coupling, keep the following factors in mind:
   1. Dependencies: How many other objects does a given object interact with? A high number of dependencies can indicate high coupling.
   2. Strength of Dependencies: How strongly is an object connected to others? If changes in one object force changes in another, that's a strong indication of tight coupling.
   3. Flexibility: Can you change or replace an object without affecting others? If yes, it indicates low coupling.
   4. Interface Complexity: Is the interface of the object simple and concise, or complex and intricate? A simple interface generally leads to lower coupling.
   5. Data Exposure: How much internal data does an object expose to others? Objects that hide their internal data and expose only necessary operations (encapsulation) typically exhibit low coupling.
4. Balancing Cohesion and Coupling:
   It's essential to strike a balance between cohesion and coupling. Aim for:
   1. High Cohesion: It makes the system more maintainable and understandable. Objects with high cohesion are typically more robust, as they encapsulate a single responsibility or function.
   2. Low Coupling: It makes the system more modular and easier to modify. With low coupling, changes in one module or object don't necessitate changes in others.
5. Conclusion:
   In object modeling, cohesion and coupling are paramount metrics for assessing the quality of objects. By ensuring high cohesion and low coupling, developers can design systems that are robust, maintainable, and scalable. Regular reviews, refactoring, and the judicious use of design patterns can help achieve and maintain these ideals throughout the software development lifecycle.

Defining objects is best accomplished in two phases.

1. First, define the encapsulated view of the object by defining only the purpose and the interface.
2. Then define the internal workings, the implementation of the data and behavior that support the purpose and interface. Over time, the purpose and interface will remain relatively stable, but the implementation can change as often as needed without disruption to other objects. The object may even be replaced with another object with the same purpose and interface but an entirely different implementation.

It is also useful to distinguish encapsulated knowledge from explicit knowledge. Encapsulated knowledge is not precisely explicit, even though this term has generally been paired with implicit knowledge, because it is knowledge concealed from its users, and explicitness implies observability.
Encapsulated knowledge is distinguishable from codified knowledge primarily along the dimension of observability which has implications for the appropriability of value. The observability of explicit, codified knowledge makes it susceptible to misappropriation. Encapsulated knowledge, on the other hand, facilitates the marketing of knowledge since it can only be partially misappropriated through expensive reverse engineering.
Finally, both codification and encapsulation are motivated by a desire to inexpensively transfer knowledge. While codification is a process that reduces complexity, encapsulation preserves complexity. The value of encapsulation lies in the avoidance of the cost of learning to make use of the encapsulated knowledge. For example, utility can be realized from the use of knowledge encapsulated in a computer or an automobile apart from having to learn why they work. The vast majority of transactions that occur in consumer markets involve the purchase of some form of encapsulated knowledge.

Encapsulation is sometimes also called information hiding because the implementation of an object is hidden. Unfortunately, this description ignores the more important aspect of encapsulation, which is what an object exposes. To illustrate, given a set of devices such as a radio, a TV, and phone, what would you need to know about them to place a call? You are probably thinking, “I just need to know how to use the phone.” But you actually need to know two things about each device: its purpose and interface.

First you need to know which device is designed for the purpose of making calls. Second, you need to know the interface of the device, that is, how to initiate a call, place a call, and terminate a call. For an object to be useful, that object has to expose both its purpose and its interface.
Some people say that the interface defines an object. Be careful. Many objects can share the same interface but have a different purpose. For example, a TV and a VCR share much of the same interfaces, such as volume controls and channel changing. But a TV cannot play tapes, and a VCR cannot display the contents of tapes. The two objects are designed for different purposes.

To use a phone, do you need to know how it transforms the mechanical press of a button into an electronic pulse? No. This part of the phone is hidden. The implementation of the phone’s interface and the data it uses for the implementation are hidden.

Design based on encapsulation is a major key to creating reusable and interchangeable objects. Just as in physical objects, like disk drives or car engines, all you need to know is the purpose and the interface to determine whether one device may be used in place of another.

Click the Exercise link below to identify which aspects of two common objects are hidden or exposed.
Hidden Exposed Object Aspects - Exercise