Comments on: The Three Reasons for Data Encapsulation

By: Aaron

Aaron — Wed, 17 Oct 2007 21:54:43 +0000

I need to see a good explanation from someone, about why you would protect a data member, and have a public getter AS WELL AS a setter, instead of just making the member public.

I’m a developer, and all of my schooling is in software. However, everyone I work with (for the most part) are all EE majors, and are all 10 years older than I am. I realized that I have no explanaition to give them, of why it is better to protect your data, even if public functions allow changes that would give the same effect as leaving the members public in the first place.

Aaron

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Fri, 02 Jun 2006 10:51:41 +0000

The 24 hour clock example was addressed in the previous post. In brief, you can add new methods that have different conditions; but under no circumstances is a subclass allowed to relax the postconditions of methods it overrides in the superclass. That’s a violation of polymorphism. If you do that, the subclass is no longer a proper instance of the superclass. Code that depends on getting a value between 1 and 12 back from the getHours() method will break when passed an instance of the subclass that returns values between 0 and 23.

This is almost as bad as going back and changing the original class so that its getHours() method returns a value between 0 and 23. You’ve broken compatibility, and you could do this because the class was not closed. Do you need to do this sometimes? Sure, but subclassing has not gained you anything. Don’t labor under the illusion that merely because you’ve subclassed instead of changing the base class, you haven’t broken anything. You absolutely have.

The solution is simple: add new methods to the subclass that do what you want. Do not overide and break the existing methods, conditions and invariants.

By: Gp

Gp — Thu, 01 Jun 2006 17:39:11 +0000

I agree with making things private when they shouldn’t be used by anyone else. But that doesn’t mean you need to have less interfaces. The “interface” of the system should be well known so that the complexity of using the interface becomes a question for the documentation “what interface do I use to accomplish X?” Unless you have an entirely closed system (even to internal changes), this question will always come up.

“Finally, we get to the first thing most textbooks cover. Separating implementation from interface allows the implementation to vary independently of the interface. For instance, you can switch a class from storing persistent data in a file to storing it in a database or vice versa. Sometimes this is important; but be honest: how many times have you really needed to do this? Out of the thousands of classes youâ€™ve written, how many have had significant changes in their internal data structures? Maybe 1 in 10? And in how many have you actually needed multiple simultaneous implementations? Maybe 1 in 100, or less?”

Any platform that has a plugin interface will need this kind of flexibility. I deal with this daily. Each plugin has its own schema of data. The domain knowledge in the plugin is entirely separated from the system inerfaces.

Now, I am not sure if you are arguing that all “design by interface” is bad or are you just saying that “you need to be able to close the interface when you want to”.

I am firmly behind the latter point:
To your clock example. It looks like you have the class for an analog clock face. Down the road your Product Manager asks you to develop a digital clock face. Now there is a problem, digital clock faces usually have AM and PM indicators on North American clocks. Also imagine that you need to develop for Europe and need a digital clock that handles 24-hour time. How would you be able to do that while still maintaining the current class as it is implemented? You can’t subclass and override your Final methods, so you would have to rewrite your clock class entirely to fit this change in. If you had built an IClock interface that has “contracts” for the constructor Clock (hrs, min) as well as virtual methods for setHours, setMinutes methods. Your “final” class would be “AnalogClock12HR”, and now you can build “DigitalClock12HR” as well as “DigitalClock24HR”. Now tell me how designing by interface does not let you perform data encapsulation. You can entirely close your class while letting the structure be flexible.