Comments on: The Three Reasons for Data Encapsulation

By: Black pinstripe suit

Black pinstripe suit — Sat, 27 Aug 2011 06:41:32 +0000

Sorry, I dont have much time to say why cause Im in a hurry and happen to read your post, nonetheless i feel I have to write you that I strongly disagree with you. Ill come back and explain myself better later. Cheers -instantempo

By: why do dogs eat poop

why do dogs eat poop — Thu, 30 Jun 2011 07:06:43 +0000

My good friend normally linked me to this web-site unfortunately this is actually the very first post I had checked out up to now. Im quite fascinated and so now a fan.

By: upper east side apartments

upper east side apartments — Mon, 27 Jun 2011 02:17:30 +0000

Was actually doing a search and came across this site. I must say that this info is on point! Keep writing more. I will be following your sites

By: miles zarathustra

miles zarathustra — Wed, 07 Apr 2010 02:59:16 +0000

This is precisely why I dislike dependency injection – by forcing a public getter and setter, it essentially forces all of your fields to be public. True, one can enforce limits in the ‘set’ method, but nobody ever seems to bother. After all, who has the time to meddle with each of the overwhelming myriad of get and set methods generated by the IDE?

My personal preference is to enforce immutablilty when possible (by only setting from the constructor) and then limiting the number of fields with public ‘set’ methods to those strictly required.

Just my take on it, YMMV.

-= miles =-

By: Kislay

Kislay — Tue, 30 Mar 2010 05:12:27 +0000

Hi J H ,
As you said “If you make an object public instead of providing a get and set, then you can never change the object without affecting external users.” Can you please explain this in programming way. I am not able to understand what you are trying to say.
Please explain bit more .

Thanks

By: J H

J H — Tue, 15 Dec 2009 05:16:38 +0000

Aaron,
Answering your comment is an act of necromancy, but your comment was, too, so:
If you make an object public instead of providing a get and set, then you can never change the object without affecting external users. You could say “so what” to that, but your software may undergo many revisions including changing the way data is organized. Right now the public object might be a stand-alone float, tomorrow you might want to put it into a record, etc.. As long as you don’t rename the get and set, you can change your objects’ names without affecting others.
That is the real value of encapsulation: not “hiding” what you have or do from the eyes of other developers, just ensuring independence of development. It’s not a rule, it’s a benefit to be weighed against its costs.

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.