A Question on Encapsulation.

views:

126

answers:

+2 Q:

A Question on Encapsulation.

Hi,

I know that encapsulation is binding the members and its behavior in one single entity. And it has made me think that the members have to be private. Does this mean if a class having public members is not following 100% Encapsulation rule?

Thanks

Correct. No data/state in the class should be exposed unless it's a final value.

arcticpenguin 2010-05-12 20:33:58

@arcticpenguin: 1st his definition of encapsulation is not "correct" then real OO works by passing messages around. Then, the point of encapsulation is to hide the functional innerworking of a class from "objects" that sends message to it. A public value, even final, completely defeats the purpose of encapsulation and hence is not "encapsulation". For some it may have its use, but having a Java *public final* member is definitely not encapsulation, no matter your definition of OO nor your definition of encapsulation.

Webinator 2010-05-12 20:42:55

Huh? Can you say that in English? What's the point of hiding immutable data? Irregardless of what your textbook says, can you give me a good reason?

arcticpenguin 2010-05-12 21:25:41

@artic In short: You cannot speak of encapsulation if you expose any member fields. If you make changes to any of the public final fields, client code (that is other classes using your class) will possibly break.

Helper Method 2010-05-12 21:32:02

If you read my comment you will see that I said 'immutable' values.

arcticpenguin 2010-05-12 21:55:11

By change I mean for example change the type of one attribute to another. If you expose the fields, you can't do that without possibly breaking someones code.

Helper Method 2010-05-12 22:56:37

Pretty much - if you think of an object as having state, now anybody can modify the state of your object without you knowing. At least with setter methods you can better control the state of the object.

David Relihan 2010-05-12 20:35:54

+5 A:

Encapsulation is both data bundling and data hiding. Java allows you to expose data, but you should have a very good reason for it if you choose to do so. Member variables should be made private as a default, and only promoted to higher visibility if absolutely necessary.

Bill the Lizard 2010-05-12 20:37:51

Anyone who comes up with a good example of non-static, non-final data that should be public will get my vote.

Bill the Lizard 2010-05-12 20:42:16

bill, I worked with a Java framework, PulpCore to develop a game in the form of an applet, and in this framework, sprites do have their data publicly accessible, e.g., mySprite.alpha.set(255);

Peter Perháč 2010-05-12 21:19:08

@Peter: That looks like a setter method call.

Bill the Lizard 2010-05-12 22:01:21

There is never ever a reason to make an attribute public.

Helper Method 2010-05-12 22:54:19

@Helper, assigning directly to a member avoids the overhead of a function call and, albeit minor, can result in faster running code (esp. in tight loops) which could be an important goal of an application (e.g. graphics), right? Anyway, I agree in general, there must really be a good (i.e. measurable) reason to forfeit the safety and flexibility of an indirect setter, but to say "never ever" seems extreme...

maerics 2010-05-13 00:21:53

@Bill, alpha is an object of type Fixed which provides the set() and get() methods but there is nothing to stop me from assigning mySprite a different Fixed object for alpha. e.g., mySprite.alpha = otherAlpha;

Peter Perháč 2010-05-13 09:18:44

+2 A:

It means that internal fields (that you want to encapsulate in your class) should be private and only exposed via getter, setters, property's etc. Hiding and bundling the internal members of your class and controlling access through some method provided in your particular framework java (getters setters), .net (properties) etc is encapsulation.

And to answer your question why would you implement encapsulation? Well it so that you can control access to an internal member of you class. For instance if you had an integer field that you only wanted set to values in the range from 1 - 10. If you exposed the integer field directly there is no mechanism to keep a consumer from setting values outside your desired range. However, you can achieve this through encapsulation by exposing your internal int field though a setter or property thus allowing you to add validation code within the setter or property to "police" what values get set to your internal field.

Enjoy!

Doug 2010-05-12 20:39:57

C# has "properties" specifically for this purpose. They are basically methods, but with a more narrow usage such as providing public access to a private data member, validation, or applying some other business logic when reading/writing the data member.http://msdn.microsoft.com/en-us/library/w86s7x04.aspx

JohnB 2010-05-12 21:33:05

ansaurus

tags:

views:

answers:

A Question on Encapsulation.

related questions