Encapsulation and Abstraction: Separating Myths from Reality

No, encapsulation is not always a result of abstraction. In this discussion, we will explore the distinction between encapsulation and abstraction, and provide real-world examples to illustrate these concepts.

Understanding Encapsulation and Abstraction

Encapsulation and abstraction are fundamental concepts in object-oriented programming, often used interchangeably but bears different meanings. Abstraction is about hiding the complexity of the implementation details to show only necessary features. Encapsulation, on the other hand, is about bundling data and methods that operate on the data so that other parts of the program can only interact with the class through well-defined interfaces and cannot access the object's internals directly.

Abstraction without Encapsulation: A Common Misconception

To illustrate the separation of these concepts, let's consider a simple example:

class MyClass {public:    Type1 getData1() const;    void setData1( Type1 d1 );    Type2 getData2() const;    void setData2( Type2 d2 );private:    Type1 data1;    Type2 data2;};

Here, we see a class 'MyClass' with public getter and setter methods for properties data1 and data2. While 'MyClass' represents the abstraction of a specific concept (such as a Person or a Coordinate), it does not properly encapsulate its internal data. The user of this class would need to know how Type1 and Type2 work in order to use it effectively, which makes it non-compliant with the Law of Demeter.

The Law of Demeter states that an object should not have detailed knowledge about the internal structure of other objects. If a object of type A uses an b object of type B internally, the user of the object a should not be aware of b in order to use a correctly. In our example, users of MyClass are required to know about Type1 and Type2, which violates this principle.

Comprehensive Encapsulation

For a class to be fully encapsulated, the internal state and behavior should be isolated from the external environment. This is where the Law of Demeter kicks in. Consider a class for a Person or a Car.

Example: Person

If we replace MyClass with Person and the getter/setter methods with getName and getBirthDate, respectively, we can argue that:

Retrieving the name and birth date are behaviors that a person can be expected to have.

In this case, the class Person is both abstracted and encapsulated properly. The user can get and set these properties without needing to know the internal implementation details.

Example: Car

Now, consider the same MyClass but as Car with getTank and getMotor. Quite similarly:

Directly accessing the tank or motor would be an internal concern of the car and not something a user would need to interact with directly.

In both cases, the use of getter and setter methods should align with the expected behaviors of the class. For instance, Car does not necessarily provide direct access to its Motor or Tank for external manipulation.

Setter Methods and Encapsulation

Setter methods are another critical aspect of encapsulation. They allow controlled modification of the internal state of an object. For example, in a Person class, setting the name and address should be handled carefully. While getting the name or birth date is essential and expected, changing these values might not always be appropriate.

Addressing Data That Should Not Change

Data like a person's name or birth date are typically immutable once set. Allowing users to change them can lead to unexpected issues. Instead, we should focus on methods that make sense within the context of the class:

class Person {public:    void moveToString(const std::string newCity, const std::string newStreet, const int newNumber);    void changePhoneNumberInt(newProvider);};

In this case, we define methods that encapsulate the internal state change. These methods perform the necessary verification and administrative work, adhering to the Law of Demeter and the principle of minimal coupling.

Conclusion

Encapsulation and abstraction are not inherently linked. Abstraction is about minimizing complexity, while encapsulation is about isolating the internal workings of an object. To achieve correct encapsulation, we need to ensure that our methods align with the expected behaviors of the class and adhere to principles like the Law of Demeter. This approach ensures that our classes are robust and maintainable, protecting against undesirable unintended modifications.

Keywords

Keywords: encapsulation, abstraction, law of demeter