Hi
I have a main class A that create an istance of a class B that create an istance of class C.
Class C modify 6 variables.
That variables can be read from class A and/or class B.
Is correct define that variables as protected static in class A or which other ways there are?
> Hi
>
> I have a main class A that create an istance of a
> f a class B that create an istance of class C.
...
> Class C modify 6 variables.
> That variables can be read from class A and/or class
> B.
Sorry, I can't follow you from here. Is there a way for you to write a small example?
> Is correct define that variables as protected static
> in class A or which other ways there are?
There is almsot no reason to define variables as somethig other than private. Whether they're static or not depends on whether you want them to be shared among all instances of a class or whether each instance should have its own one,
> Hi
>
> I have a main class A that create an istance of a
> f a class B that create an istance of class C.
> Class C modify 6 variables.
> That variables can be read from class A and/or class
> B.
>
> Is correct define that variables as protected static
> in class A or which other ways there are?
If it is useful to you, yes, it is.
> > Is correct define that variables as protected
> static
> > in class A or which other ways there are?
>
> There is almsot no reason to define variables as
> somethig other than private. Whether they're static
> or not depends on whether you want them to be shared
> among all instances of a class or whether each
> instance should have its own one,
Hmmm, I think sometimes it would be strategically interesting, and good.
> "Strategically interesting"? The less visible a
> variable is to anyone, the better.
LOL!!!! A silly example:
class Father {
/* total amount of money that belongs to family */
protected static double money;
protected void buySomething(double value) {
//the father spend money here
Father.money -= value;
}
}
class Child extends Father {
protected void buySomething(double value) {
//the child spend money here
Father.money -= value;
}
}
I磛e never made my fields as protected static yet, but I think in rare cases it would be good.
> > Is the next piece of advice going to be make all
> > classes final?
>
> Why not? Because classes that are not designed to be
> inherited from should not be inherited from.
That is a true statement.
But to say all classes should be final or "The less visible a variable is to anyone, the better." are false.
Why not say "what is suitable on the basis of a well planned design is probably the right thing to do" ?
> > "Strategically interesting"? The less visible a
> > variable is to anyone, the better.
>
> LOL!!!! A silly example:
> > class Father {
>/* total amount of money that belongs to family */
>protected static double money;
>
>protected void buySomething(double value) {
>//the father spend money here
>Father.money -= value;
>}
> }
>
> class Child extends Father {
>
>protected void buySomething(double value) {
>//the child spend money here
>Father.money -= value;
>}
> }
>
>
> I磛e never made my fields as protected static yet,
> but I think in rare cases it would be good.
Yes, that's a very silly example. A Child should not extend a Father, and the attribute money should not be static. Do all fathers share the same amount of money?
Kaj
> LOL!!!! A silly example:
> > class Father {
>/* total amount of money that belongs to family */
>protected static double money;
>
>protected void buySomething(double value) {
>//the father spend money here
>Father.money -= value;
>}
> }
>
> class Child extends Father {
>
>protected void buySomething(double value) {
>//the child spend money here
>Father.money -= value;
>}
> }
>
LOL!!! Indeed, a silly and bad example, I didn磘 notice that I am overriding the parent method equally! I wrote this code without attention.
But I think you got the idea. I think we can consider the situation in which there is a static field, and we want to prevent this modification from classes that are not subclasses, and at the same time we want to make this static field available only for subclasses.
> But to say all classes should be final or "The less
> visible a variable is to anyone, the better." are
> false.
Why? I thought encapsulation is usually embraced, and I don't see how direct access to a variable (as opposed to a constant) actually improves something. At least use a getter or setter. I'm all for encapsulation and loose coupling.
> "Strategically interesting"? The less visible a
> variable is to anyone, the better.
I think you are talking about hidding the fields whenever possible. I agree with you. This is therecommended way in OOP. Therefore, what would we do? Writing getters and setters? OK, this is the recommended practice. But, if we are "lazy", we can change the values directly, without setter methods, and if we make the fields as static and protected, at least we are guaranteeing that the value won磘 be modified by some class that is not subclass.
But, anyway, I磛e never wrote such code, this is just an idea.
> Ive heard that there are classes in java API, that
> make some fields as public. Would it be considered a
> bad design? I dont know, I think you can do that,
> for convenience.
Yes, it's generally bad design, but it depends on what the class does. It's not that bad if the class is only a data holder. E.g. the Point class has two public fields, x and y, and it's probably for performance reasons.
Kaj
> > Ive heard that there are classes in java API,
> that
> > make some fields as public. Would it be considered
> a
> > bad design? I dont know, I think you can do that,
> > for convenience.
>
> Yes, it's generally bad design, but it depends on
> what the class does. It's not that bad if the class
> is only a data holder. E.g. the Point class has two
> public fields, x and y, and it's probably for
> performance reasons.
>
> Kaj
Exactly, thats why I said that in rare cases, it would be good and it would NOT be a bad design. Probably for performance reasons, yes.
But generally, it is always good following the Encapsulation rule, as Rene said.
Setter/getters neither hide nor encapsulate.
Point might expose its members for any of a number of reasons.
- Performance
- As a trivial data container there is no point in having methods
- The original author didn't have any idea what they were doing.
- Something else.
> Setter/getters neither hide nor encapsulate.
Uhm. I just wrote a set of getters and setters that do exactly that, because the data taype of the field is entirely different from the type accepted and returned by those methods. The egtters and setters do the necessary conversion, but still communicate the state of that "field", but hiding its handling. Other setters change a null reference of an argument (some array) to an empty array, which removes the need of checks for null. Some getters in turn provide copies of the actual field, not the real reference. So there can a lot encapsulation be done by getters and setters.
Kaj: two days ago I got told by my customer I need to "encapsulate" (by getters and setters) even final variables. "In case one day it might not be final anymore..." So while I usually do not encaspulate constants, it was required.
And: Point has getters and setters. Which aren't getters and setters the way Joe argues, either.
> > Setter/getters neither hide nor encapsulate.
>
> Uhm. I just wrote a set of getters and setters that
> do exactly that, because the data taype of the field
> is entirely different from the type accepted and
> returned by those methods.
Then it isn't the common meaning associated with the term getter/setter.
> The egtters and setters do
> the necessary conversion, but still communicate the
> state of that "field", but hiding its handling. Other
> setters change a null reference of an argument (some
> array) to an empty array, which removes the need of
> checks for null. Some getters in turn provide copies
> of the actual field, not the real reference. So there
> can a lot encapsulation be done by getters and
> setters.
I didn't say they could never provide value, what I said was that they neither hide nor encapsulate
>
> Kaj: two days ago I got told by my customer I need to
> "encapsulate" (by getters and setters) even final
> variables. "In case one day it might not be final
> anymore..." So while I usually do not encaspulate
> constants, it was required.
>
> And: Point has getters and setters. Which aren't
> getters and setters the way Joe argues, either.
The java docs I have for java.awt.Point list getX() and getY() which returne double values. There is no setX() nor setY(). Additionally the public fields of that class (x,y) have the type 'int' which would suggest to me that the methods that are provided do not fall into the meaning of getter/setter.
Well, Joe, if you define getters and setters as "methods that directly access the attribute without doing anything else", yes, then I agree, they do nothing in regards to improving design. I debated that point often enough myself. Except that you're still screwed in case the internal structure of the class changes, the attribute changing type or becoming a part of a collection or simply being calculated on the fly.
> Setter/getters neither hide nor encapsulate.
Encapsulation is a characteristic of OOP. You use encapsulation if you make the fields as private and if you want to expose their values you use methods for that.
For me, classes that have getters and setters work exactly according to the encapsulation rule. I dont understand why are you saying that setter/getters dont encapsulate. May you explain me more?
> Kaj: two days ago I got told by my customer I need to
> "encapsulate" (by getters and setters) even final
> variables. "In case one day it might not be final
> anymore..." So while I usually do not encaspulate
> constants, it was required.
I would probably solve it in another way. I would not create getters and setters for constants just because we might change something in the future. I would use the refactoring support given by the IDE to change the code later on if I had to make the field non final..... But then I'm a consultant and sometimes I have to do what I don't like to do, but I wouldn't add the getter ans setters without a (small) fight. *beep*
Kaj
> For me, classes that have getters and setters work
> exactly according to the encapsulation rule. I dont
> understand why are you saying that setter/getters
> dont encapsulate. May you explain me more?
Where's the difference betweenanObj.x = 1;
andanObj.setX(1);
withpublic void setX(int i) {
thisx = i;
}
?
You have uncontrooled and unrestricted access to a member attribute. Since member attributes are to be considered an implementation detail, you shouldn't even know that it exists. The setter as provided above is just a sorry excuse for not shutting away the member entirely. You still breach encapsulation by allowing direct access to a member.
> I would probably solve it in another way. I would not
> create getters and setters for constants just because
> we might change something in the future. I would use
> the refactoring support given by the IDE to change
> the code later on if I had to make the field non
> final..... But then I'm a consultant and sometimes I
> have to do what I don't like to do, but I wouldn't
> add the getter ans setters without a (small) fight.
> *beep*
Hey, I'm in the same boat as you. But if the customer's QA insists that "attributes, even final ones have to be private" there's not much you can do. These constants (attributes of a simple data container) were public final, and were set by constructor arguments provided from a factory. Still, no dice... *shrug*
When you use setter method instead of making the field publicly available, you can have some level of control. For example:
public void setSomething(int i) {
if (i > 10)
throw new IllegalArgumentException("Blah");
//...
}
It is one of the main benefits of encapsulation.
> When you use setter method instead of making the
> field publicly available, you can have some level of
> control.
You're moving away from the standard setter again, that way. And you still publish an implementation detail. Why does another class meddle with the local data? It's none of its business. Even the container classes, while being the simplest way, are rather an abuse of OO. If some other class needs the data, it's called feature envy and a hint that some refactoring is due.
> It is one of the main benefits of encapsulation.
Encapsulation means that you handle a black box. This box is not black at all, it's still rather transparent. You're controlling an action that is not supposed to happen in the first place.
> You're moving away from the standard setter again,
> that way.
Generally, in the most of cases, setter method does not have any kind of control about the parameter passed. Thats why you conclude that this is the "standard". But you can have this control, why not?
> And you still publish an implementation
> detail. Why does another class meddle with the local
> data?
Sorry, I didnt understand you here. Maybe thats because I have problems with English. Anyway, if I understood you correctly, does "publishing the implementation" have any relation with encapsulation? I dont think so.
> > It is one of the main benefits of encapsulation.
>
> Encapsulation means that you handle a black box. This
> box is not black at all, it's still rather
> transparent. You're controlling an action that is not
> supposed to happen in the first place.
Encapsulation means access control. Encapsulation guarantees that you can have some level of control of the values inside this black box. Or, at least, one day you can have, if you decide to modify your code.
Encapsulation is not related with "hiding the fields".
> Encapsulation means access control.
Encapsulation means "knot knowing whether there is anything to access at all". You are not to control the values inside the black box, as you are not supposed to be aware they they exist at all.
http://en.wikipedia.org/wiki/Information_hiding
Forwarded from "Encapsulation".
> detail. Why does another class meddle with the local
> data? It's none of its business. Even the container
> classes, while being the simplest way, are rather an
> abuse of OO. If some other class needs the data, it's
> called feature envy and a hint that some refactoring
> is due.
What would be the reason that motivated "the creator" of the getter/setter to create that? The only reason is that you can have control. Otherwise, why do getter/setter methods exist? Why did "the creator" create that? Why doesnt a simple class with simple public fields, and without any kind of getter/setter, exist? Getter/setter is undoubtelly very important , isnt it? It achieved a high level of popularity. I think Getter/setter wouldnt be so famous in programming world if "the creator" didnt have a very good reason for creating that. This reason is called Encapsulation.
If we dont consider Encapsulation, we can conclude that the context is totally favorable to not creating getters/setters methods. "Why the hell I need those getters and setters? It just make my class more complicated!!" someone would ask. But considering the benefits of Encapsulation, getters and setters are good.
> What would be the reason that motivated "the creator"
> of the getter/setter to create that?
"Lazy" design. "Lazy" as in pragmatic and appropriate, and not by the textbook.
> The only reason
> is that you can have control. Otherwise, why do
> getter/setter methods exist?
They shouldn't.
> Why did "the creator"
> create that? Why doesnt a simple class with simple
> public fields, and without any kind of getter/setter,
> exist?
Because it's even worse than getters and setters.
> Getter/setter is undoubtelly very important ,
> isnt it? It achieved a high level of popularity. I
It reached a high popularity among my co-tudents because the professors taught "setX(int i) { thix.x = i; }" means "encapsulation". Wich is BS.
> think Getter/setter wouldnt be so famous in
> programming world if "the creator" didnt have a very
> good reason for creating that. This reason is called
> Encapsulation.
It is not encapsulation. What do you encapsulate? Encapsulation means "no access at all", not "controlled access".
> If we dont consider Encapsulation, we can conclude
> that the context is totally favorable to not creating
> getters/setters methods.
It is. http://wiki.java.net/bin/view/People/SmellsToRefactorings See "feature envy". If you need the data outside the class, it might not have to be inside in the first place.
See also: http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Though of course Holub is always two steps over the edge.
> > Setter/getters neither hide nor encapsulate.
>
> Encapsulation is a characteristic of OOP. You use
> encapsulation if you make the fields as private and
> if you want to expose their values you use methods
> for that.
>
> For me, classes that have getters and setters work
> exactly according to the encapsulation rule. I dont
> understand why are you saying that setter/getters
> dont encapsulate. May you explain me more?
Because you are exposing the data.
As an example the 'length' of a string does not expose the data of String because the class could be recalculating it each time.
However if Point did have a setters/getters for X and Y then it would be exposing it directly.
The reason why this can be a problem is that users then become reliant on the data of the class rather than on the behavior of the class.
Of course in any real application some data will always be exposed, but on needs to minimize it.
> Well, Joe, if you define getters and setters as
> "methods that directly access the attribute without
> doing anything else", yes, then I agree, they do
> nothing in regards to improving design.
That is what I meant.
> I debated
> that point often enough myself. Except that you're
> still screwed in case the internal structure of the
> class changes, the attribute changing type or
> becoming a part of a collection or simply being
> calculated on the fly.
That happens very, very seldom. And when it does it is so unlikely that the entire structure of subsystem does not also change (thus requiring vast changes anyways) that any possible impact is immeasurable.
And that is vastly offset by the misuse of setters/getters where people think that they are 'safe' in adding such methods either globably (every attribute) or just as a quick 'fix' that one needs to emphasize that is it never a good thing.
> > Kaj: two days ago I got told by my customer I need
> to
> > "encapsulate" (by getters and setters) even final
> > variables. "In case one day it might not be final
> > anymore..." So while I usually do not encaspulate
> > constants, it was required.
>
> I would probably solve it in another way. I would not
> create getters and setters for constants just because
> we might change something in the future. I would use
> the refactoring support given by the IDE to change
> the code later on if I had to make the field non
> final..... But then I'm a consultant and sometimes I
> have to do what I don't like to do, but I wouldn't
> add the getter ans setters without a (small) fight.
> *beep*
There is another reason for that though. Some constants will get compiled into the code that uses it. Thus all of the code must be recompiled. That isn't the case with a method.
> When you use setter method instead of making the
> field publicly available, you can have some level of
> control. For example:
And again I didn't say that they never provided value.
> public void setSomething(int i) {
>if (i > 10)
>throw new IllegalArgumentException("Blah");
>
>//...
> }
>
And do all of your setters/getters look like that?
Do 90%?
Do 1%?
Note that I also said 'getters' as well.
> It is one of the main benefits of encapsulation.
Except that the internals are no longer hidden
> > detail. Why does another class meddle with the
> local
> > data? It's none of its business. Even the
> container
> > classes, while being the simplest way, are rather an
> > abuse of OO. If some other class needs the data, it's
> > called feature envy and a hint that some
> refactoring
> > is due.
>
> What would be the reason that motivated "the creator"
> of the getter/setter to create that? The only reason
> is that you can have control. Otherwise, why do
> getter/setter methods exist?
Exposing data is required in non-trivial applications (perhaps even trival ones.)
That doesn't mean one should do it all the time.
And often setters/getters exist because students take it on faith because teachers use them as the simplest sort of method that one can build.
> Why did "the creator"
> create that? Why doesnt a simple class with simple
> public fields, and without any kind of getter/setter,
> exist?
It does - read the DTO pattern in J2EE.
See java.awt.Point.
> Getter/setter is undoubtelly very important ,
> isnt it? It achieved a high level of popularity. I
> think Getter/setter wouldnt be so famous in
> programming world if "the creator" didnt have a very
> good reason for creating that. This reason is called
> Encapsulation.
Nope. It is a misunderstanding of what the point of OO is and what value some simple methods provide. Just because one uses an OO language doesn't mean that every thing created in the language is an idealization of some OO concept.
And real applications always need comprises anyways. These days I tend to use getters/setters extensively but only for a specific type of object - DTOs. In doing so I understand that the DTO is not a true object. Instead it is just a convienent way to group related attributes together and provide a convenient source of some functionality (not behevior) as well.
>
> If we dont consider Encapsulation, we can conclude
> that the context is totally favorable to not creating
> getters/setters methods. "Why the hell I need those
> getters and setters? It just make my class more
> complicated!!" someone would ask. But considering the
> benefits of Encapsulation, getters and setters are
> good.
Would you claim that java.lang.Math has no use?
> > When you use setter method instead of making the
> > field publicly available, you can have some level
> of
> > control. For example:
>
> And again I didn't say that they never provided
> value.
>
> > public void setSomething(int i) {
> >if (i > 10)
> >throw new IllegalArgumentException("Blah");
> >
> >//...
> > }
> >
>
> And do all of your setters/getters look like
> that?
>
> Do 90%?
>
> Do 1%?
OK. It is just an example. But I admit: like in your case, my getters/setters are always simple like this:
public class Things {
private thingOne;
private thingTwo;
//etc...
public setThingOne(thing) {
thingOne = thing;
}
public getThingOne() {
return thingOne;
}
public setThingTwo(thing) {
thingTwo = thing;
}
public getThingTwo() {
return thingTwo;
}
//etc...
}
And nothing else. But the fact is that Encapsulation guarantees the control of what information you make available.
> Note that I also said 'getters' as well.
Example with getter:
public class Things {
private thingOne;
//etc...
public getThingOne(thing) {
if (condition) {
return thingOne;
} else {
return otherValue;
}
}
//etc...
}
Again, Ive never needed to write that kind of getter. I think you havent, either. But, again, the fact is that Encapsulation guarantees the control of what information you want to make available. Encapsulation guarantees this flexibility.
> > It is one of the main benefits of encapsulation.
>
> Except that the internals are no longer hidden
Well, if we consider the way that getters/setters are written in these days, actually, we can conclude that we lost encapsulation. Now I can understand you. What you said makes all the sense of the world. But I think that when getters/setter were created, the main motivation was encapsulation. Of course, if we always use getters/setter, and we are sure that the way we use them always breaks the encapsulation rule, then why do we need to use encapsulation? We dont need that! Just make the fields publicly available. Ok, I understand you.
> > If we dont consider Encapsulation, we can
> conclude
> > that the context is totally favorable to not
> creating
> > getters/setters methods. "Why the hell I need
> those
> > getters and setters? It just make my class more
> > complicated!!" someone would ask. But considering
> the
> > benefits of Encapsulation, getters and setters are
> > good.
>
> Would you claim that java.lang.Math has no use?
Hmmm? Sorry, I dont get that. Im not claiming that. I dont know why you metioned Math class. Did you mention because Math doesnt have any kind of setter method? Although Math doesnt have that, Math follows encapsulation! Math class is the perfect example of demonstration of encapsulation!
> Well, if we consider the way that getters/setters are
> written in these days, actually, we can conclude that
> we lost encapsulation. Now I can understand you. What
> you said makes all the sense of the world. But I
> think that when getters/setter were created, the main
> motivation was encapsulation.
No. The motivation was to conveniently bypass encapsulation.
> Of course, if we always
> use getters/setter, and we are sure that the way we
> use them always breaks the encapsulation rule,
> then why do we need to use encapsulation?
Shouldn't the question be "why do we need getters and setters then"? Why does everyone doing something wrong mean that it's suddenly right?
I would surely want to emphasize the priority on encapsulation, not on using getters and setters. (And please provide a source that says "the point of encapsulation is to control the access to impementation details" as you continue to claim.
> Hmmm? Sorry, I dont get that. Im not claiming
> that. I dont know why you metioned Math class. Did
> you mention because Math doesnt have any kind of
> setter method? Although Math doesnt have that, Math
> follows encapsulation!
Because it doesn't have that it follows encapsulation.
> Hmmm? Sorry, I dont get that. Im not claiming
> that. I dont know why you metioned Math class. Did
> you mention because Math doesnt have any kind of
> setter method? Although Math doesnt have that, Math
> follows encapsulation! Math class is the perfect
> example of demonstration of encapsulation!
:huh:, I guess I'm still too sleepy to think, as I think encapsulation needs some data to emcapsulate.
Math has no data. It is just a set of methods in one tasty package.
> :huh:, I guess I'm still too sleepy to think, as I
> think encapsulation needs some data to emcapsulate.
> Math has no data. It is just a set of methods in one
> tasty package.
So I'm not the only one who thinks that Math is a strange example.. phew. But the point is probably: do we know that it has no data? Maybe it does have and it's completely encapsulated from us.
> So I'm not the only one who thinks that Math is a
> strange example.. phew. But the point is probably: do
> we know that it has no data? Maybe it does have and
> it's completely encapsulated from us.
Ahh, good point. It could be using look-up tables, and we'd never know (<looks about nervously/>.)
Marcelo, according to everyone, this is ****:
class TaxCalculator {
public double taxRate = 0.30;
// ...
}
According to you, encapsulation would be
class TaxCalculator {
private double taxRate = 0.30;
public double getTaxRate() {
this.taxRate();
}
public double setTaxRate(double rate) {
if (rate < 0 && rate > 1) throw new IllegalArgumentException("...");
this.taxRate = rate;
}
// ...
}
According to me, encapsulation would be
class TaxCalculator {
private double taxRate = 0.30;
public double getTaxAmountFor(double value) {
return value * this.taxRate;
}
// ...
}
I don't know about any taxRate attribute, and am happily oblivious of whether the tax calculation needs some fixed value or dark magic in its calculation. If you need something done and you need some other class's data for it, let the other class do it instead. You're allowed to push data, but pulling data is not nice. What if something like a tax-free base amount of income is introduced? What if a flat tax is introduced?
Even with your controlling getter, you have a problem with changing the implementation details in your design. And there is certainly no encapsulation, everybody but the tax calculator needs to know how taxes are calculated - otherwise, they wouldn't know what to do with the taxRate they got from that getter. Encapsulation would mean "the entire mechanism of tax calculation is hidden". Not controlled. Hidden, with nobody being allowed to see.
Getting and setting fields isn't encapsulation anymore than reading and writing to public fields is. It does provide advantages, but it does not provide encapsulation. Of course, it's easy for an API to become so complex it's a hindrance if you try too hard to satisfy academic concerns. I'll give an example since it's a package I've been working on for a couple weeks here and there:
public interface ImageRenderer<E> {
public void paintImage(Graphics g, Component c);
public E getSource();
public int getWidth();
public int getHeight();
}
Does this break encapsulation? My first inclination is to say no. It's responsibility is to paint an image. How it accomplishes this is not known. The fields it has aren't known. How it calculates the width and height aren't known either. Yet it seems you would say because we know it has a source image, and we know it has a width and height, that it breaks encapsulation?
Of course this package as a whole gets kind of tricky when you have to deal with APIs like Swing and AWT, so perhaps it's not a fair example.
> public class Things {
>private thingOne;
>//etc...
>public getThingOne(thing) {
>if (condition) {
>return thingOne;
>} else {
> return otherValue;
>}
>}
>//etc...
> }
>
> Again, Ive never needed to write that kind of
> getter. I think you havent, either. But, again, the
> fact is that Encapsulation guarantees the control of
> what information you want to make available.
> Encapsulation guarantees this flexibility.
>
You are making an argument based on something that you have never needed to do.
Moreover you are claiming because there could be value (which I never claimed otherwise) that it thus 'encapsulates' it.
It doesn't.
And I have written getters that way before.But I didn't do it because I thought it was encapsulating anything. I did it because that particular functionality was convienent.
> > > It is one of the main benefits of encapsulation.
> >
> > Except that the internals are no longer hidden
>
> Well, if we consider the way that getters/setters are
> written in these days, actually, we can conclude that
> we lost encapsulation. Now I can understand you. What
> you said makes all the sense of the world. But I
> think that when getters/setter were created, the main
> motivation was encapsulation.
You mean when the idea came into existence back in the 70's or so?
Yes that might have been the intent then.
Do you mean when someone uses it now? That might be their intent but now we know better.
> Of course, if we always
> use getters/setter, and we are sure that the way we
> use them always breaks the encapsulation rule,
> then why do we need to use encapsulation?
Huh? I don't believe anyone said that nothing at all provided encapsulation.
> We dont
> need that! Just make the fields publicly available.
No one said that.
> > > If we dont consider Encapsulation, we can
> > conclude
> > > that the context is totally favorable to not
> > creating
> > > getters/setters methods. "Why the hell I need
> > those
> > > getters and setters? It just make my class more
> > > complicated!!" someone would ask. But
> considering
> > the
> > > benefits of Encapsulation, getters and setters
> are
> > > good.
> >
> > Would you claim that java.lang.Math has no use?
>
> Hmmm? Sorry, I dont get that.
Myself I don't consider that java.lang.Math provides encapsulation of anything.
It is useful though. Just as it is sometimes useful to use setters and getters.
> Does this break encapsulation? My first inclination
> is to say no. It's responsibility is to paint an
> image. How it accomplishes this is not known. The
> fields it has aren't known. How it calculates the
> width and height aren't known either. Yet it seems
> you would say because we know it has a source image,
> and we know it has a width and height, that it breaks
> encapsulation?
>
Whether it breaks it or not depends on where it is getting the values.
And even if it breaks it, it doesn't make it wrong.
> Whether it breaks it or not depends on where it is
> getting the values.
>
> And even if it breaks it, it doesn't make it wrong.
I was under the impression it didn't matter where or how it gets the values. So long as it conforms to it's API the implementation is hidden, isn't that encapsulation?
> > Whether it breaks it or not depends on where it is
> > getting the values.
> >
> > And even if it breaks it, it doesn't make it
> wrong.
>
> I was under the impression it didn't matter where or
> how it gets the values. So long as it conforms to
> it's API the implementation is hidden, isn't that
> encapsulation?
Not really. Which of the following exposes the internals of the class more?
int getWidth() { return width; }
double getSize() { return (double)width * length; }
In particular look at the return type of each.
Jschell and Rene: I think it would be a good idea if we discussed about our point of view when we mention Encapsulation, because we are having a lot of divergences!
But, before I say what exactly I mean about encapsulation, I would like to establish some points (if you dont care):
1) Before we talk about getters/setters, may we get a consensus about the concept of encapsulation? Or, at least, may we try to get a consensus?
2) I think all those main concepts of OOP (inheritance, encapsulation, etc) must be sustained by a consistent theoretical base, to prove that the concepts are really good and can be done in practice. Although, sometimes the theory in practice is other theory (expression often used in portuguese, I think you can understand the meaning). I think the getters/setters case we are discussing is that "other theory in practice". First of all, I want to discuss about the theory that sustains the concept, regardless the way this theory is used in practice. I think it would be good, for better clarifications. May we?
3) After that, I think we finally can discuss about getters/setters, and how the theory is used in practice.
My understanding about Encapsulation:
When we use private fields we are preventing that others access this field, right? But, more than a simple field, we are controlling the way we use to expose the information. We can control that making the fields as private and providing and interface that will be used to expose the data/informations/field values. Sorry if I am using an expression that is causing double meaning in your minds, but when I use the term access control I want to say that we are controlling the access to the internal details of the class. Isnt private keyword used when we want to prevent the direct access to the field or to the method? I think access control is a reasonable term, and it is understandable.
Rene: maybe we wont find this term exactly as I wrote in internet, but I think you understand what I mean, after my explanation. I think you are mature enough to not worring about this little terminology detail. Maybe controlled access can give a better idea.
Id really like to read your replies, please.
> > > Whether it breaks it or not depends on where it
> is
> > > getting the values.
> > >
> > > And even if it breaks it, it doesn't make it
> > wrong.
> >
> > I was under the impression it didn't matter where
> or
> > how it gets the values. So long as it conforms to
> > it's API the implementation is hidden, isn't that
> > encapsulation?
>
> Not really. Which of the following exposes the
> internals of the class more?
>
> > int getWidth() { return width; }
> double getSize() { return (double)width *
> )width * length; }
>
>
> In particular look at the return type of each.
How is it exposing internals? Is using List.size() exposing internals? If the API defines that getWidth() returns the "Area in pixels needed to render." is that an internal detail? I would think how it determines the area needed would be the internal detail. For example, it could be the width of the image, or it could be the width of an image after it's gone through a transform, or it could be the width of the image, plus a border, plus an inset. It's basically saying "This is how much width I need to display myself." I don't see how that violates encapsulation.
Then again, perhaps it's not a typical "getter" at all and it is an irrelevent example of how getSomething() isn't always a "getter"?
>
> But, before I say what exactly I mean about
> encapsulation, I would like to establish some points
> (if you dont care):
> 1) Before we talk about getters/setters, may we get a
> consensus about the concept of encapsulation? Or, at
> least, may we try to get a consensus?
>
A getter/setter is a method whose point of existance is to provide public access to a private data member.
> 2) I think all those main concepts of OOP
> (inheritance, encapsulation, etc) must be sustained
> by a consistent theoretical base, to prove that the
> concepts are really good and can be done in practice.
> Although, sometimes the theory in practice is
> other theory (expression often used in
> portuguese, I think you can understand the meaning).
> I think the getters/setters case we are discussing is
> that "other theory in practice". First of all, I want
> to discuss about the theory that sustains the
> concept, regardless the way this theory is used in
> practice. I think it would be good, for better
> clarifications. May we?
>
In theory a getter/setter is a 'good' thing.
In practice it is a bad thing because it does in fact expose what it should be hiding.
In the first case I suspect it is considered a 'good' thing because the object exists in isolation. And in isolation the usage is limited. In practice that isn't true.
> 3) After that, I think we finally can discuss about
> getters/setters, and how the theory is used in
> practice.
>
There are three uses in practice.
1. Provide getter/setters on everything. The vast majority of these methods are not used but they exist 'just in case'.
2. Provide getter/setters on everything. The vast majority of these methods are used.
3. Provide the appropriate exposure either via getters/setters or public access based on design. There are very few getters/setters.
1 and 3 are the same except that in 1 the developer(s) didn't realize that their correct design didn't need to expose everything.
2 represents a bad design. In all likelyhood the code is procedural rather than OO.
> My understanding about Encapsulation:
> When we use private fields we are preventing that
> others access this field, right? But, more than a
> simple field, we are controlling the way we use to
> expose the information. We can control that
> making the fields as private and providing and
> interface that will be used to expose the
> data/informations/field values. Sorry if I am using
> an expression that is causing double meaning in your
> minds, but when I use the term access control
> I want to say that we are controlling the access to
> the internal details of the class. Isnt private
> keyword used when we want to prevent the direct
> access to the field or to the method? I think
> access control is a reasonable term, and it is
> understandable.
Yes but what does that have to do specifically with encapsulation and data hiding?
Again no one said that getter/setters never have any value.
As an example...
Say I want to keep a collection of orders to customers. And I choose to implement the association via link class. And in that class I implement the link via a hash. The hash is a member of the class.
Can I provide a getter/setter that allows someone to get that hash?
If I provide that does it let someone determine how I am implementing my class?
If someone uses the getter/setter is there a way that I can change my class to use a different collection type (where I do not have to inspect everywhere my class is used to see how someone might have used my hash)?
> > int getWidth() { return width; }
> > double getSize() { return (double)width *
> > )width * length; }
> >
> > In particular look at the return type of each.
>
> How is it exposing internals?
That analogy does not work. Size() of a list is behavior of the list.
My example was written specifically to suggest that in one case there is behavior (the double) where in the second there is exposure.
> Is using List.size()
> exposing internals? If the API defines that
> getWidth() returns the "Area in pixels needed to
> render." is that an internal detail? I would think
> how it determines the area needed would be the
> internal detail. For example, it could be the width
> of the image, or it could be the width of an image
> after it's gone through a transform, or it could be
> the width of the image, plus a border, plus an inset.
> It's basically saying "This is how much width I need
> d to display myself." I don't see how that violates
> encapsulation.
The difference is in intent.
A user might need the width of an image. The user doesn't need to know that you have two buffers though and merge them to create the actual image (as an example.)
One is behavior of the object. The other is implementation detail about the object.
> Getting and setting fields isn't encapsulation
> anymore than reading and writing to public fields is.
> It does provide advantages, but it does not provide
> e encapsulation.
I cannot help but agree to a certain degree as to what you have just said over here. Polymorphism, abstraction, encapsulation are all semantics of OO programming paradigm and cannot always be explained in syntactic terms. So if someone says that encapsulation is limited to or even based on getter and setter methods I would definitely not agree with this thought. As a matter of fact as per my understanding encapsulation takes of where abstraction leaves. Consider an example of a building or even a house. A house is a collection of bricks, wood, cement, appliances etc. Whenever we are dealing with such a collection in our daily life we are basically dealing with abstraction, so when talking of a house we do not mention how much wood was used we do not define how many doors it had, whats the size of the house, it could be any house just an abstract idea. Now taking it to the next level talking of encapsulation. It takes over from where abstraction left. You are allowed to have only as much information as you need. For example you might be allowed to look at the house from a distance, you can see that it has a door, but you cannot find out if the door is a a plain door or is carved. You can count the no of doors but you cannot make up id these doors are made of wood or steel or glass, this is what encapsulation is can't say if it has something to do with implementing getter's and setters but yes it sure has something to do with how are they implemented. More of semantics than syntax.
> One is behavior of the object. The other is
> implementation detail about the object.
So if getWidth() returns a "behavior" of the object, it would not violate encapsulation? Then it wouldn't matter if getWidth() returned a private member in order to do it or whether or not it did it some other way. But then it's not really a "getter" as defined in this thread?
> I cannot help but agree to a certain degree as to
> what you have just said over here. Polymorphism,
> abstraction, encapsulation are all semantics of OO
> programming paradigm and cannot always be explained
> in syntactic terms. So if someone says that
> encapsulation is limited to or even based on getter
> and setter methods I would definitely not agree with
> this thought. As a matter of fact as per my
> understanding encapsulation takes of where
> abstraction leaves. Consider an example of a
> building or even a house. A house is a collection of
> bricks, wood, cement, appliances etc. Whenever we
> are dealing with such a collection in our daily life
> we are basically dealing with abstraction, so when
> talking of a house we do not mention how much wood
> was used we do not define how many doors it had,
> whats the size of the house, it could be any house
> just an abstract idea. Now taking it to the next
> level talking of encapsulation. It takes over from
> where abstraction left. You are allowed to have only
> as much information as you need. For example you
> might be allowed to look at the house from a
> distance, you can see that it has a door, but you
> cannot find out if the door is a a plain door or is
> carved. You can count the no of doors but you cannot
> make up id these doors are made of wood or steel or
> glass, this is what encapsulation is can't say if it
> has something to do with implementing getter's and
> setters but yes it sure has something to do with how
> are they implemented. More of semantics than syntax.
I think you have to consider how getters are being defined in this discussion. I don't think it's an objection to a getSomething() method existing that happens to return a private member. I think it's an objection to saying that just becuase you used getSomething() to return a private member that is an implementation detail you've accomplished encapsulation. The assumption is that it's an implementation detail and not "behavior" to begin with.
> @jschell:
>
> Would it be accurate to say then that encapsulation
> is broken in the API?
API? You mean the java API?
I know the Java API is broken in places in terms of design. As far as exposure I haven't found any explicit ones myself.
> I don't see it returning a
> private member as being relevent. Isn't the issue
> with whether or not the API exposes part of the
> object that's supposed to be hidden?
I believe I already pointed out that applications must expose data sometimes. That is one of the differences between theorectical and practical.
> > One is behavior of the object. The other is
> > implementation detail about the object.
>
> So if getWidth() returns a "behavior" of the object,
> it would not violate encapsulation?
Correct - as long as...
1. The return type did not expose the implementation.
2. The method itself was behavior and not just exposing data.
> Then it wouldn't
> matter if getWidth() returned a private member in
> order to do it or whether or not it did it some other
> way. But then it's not really a "getter" as defined
> in this thread?
Nope.
Getter/setters are used to expose data. That is how they are used and that is how they are thought of.
When I create a collection object and I decide to add a size() method I do so not because I want access to a particular data member but because I want to know the size of the collection.
When I add getters/setters it is solely because I want access to a data member (and I am adding some convienence functionality associated with accessing that data.)
Using the house example...
The house certainly has a number of rooms.
But the mailman doesn't care at all how many rooms the house has. I can certainly choose to expose the number of rooms 'just in case' the mailman needs it in the future.
But once I do that then if I change what 'number of rooms' means then I am going to have to figure if the mailman is using it, how the mailman is using it and if so then make adjustments to account for that usage.
And finally one must ask oneself why the mailman would ever need to know the number of rooms in the first place? What possible purpose does it server the mailman? Maybe because the mailman isn't actually the mailman but is instead the house cleaner.But in that case the design is flawed and thus not only is the behavior of the house and mailman wrong but the relationship between them is probably ill-defined as well.
> A getter/setter is a method whose point of existance
> is to provide public access to a private data
> member.
Id say that getter/setter in practice, and generally, is used to provide public access to private data member. Although, theoretically, it is just a choice, chosen by the developer. The main point is that the developer has this choice. The developer can get or set anything he/she wants, when he/she uses getters/setters. Theoretically, it is a great flexibility. If he/she will take the advantages of this flexibility, well...this is other conceptual problem. The practice proves that 95%, or even more, of DTO (Data Transfer Object pattern) objects simply work as you say: they simply provide public access to a private data member, nothing else. This is my feeling, my opinion (that 95%). Thats why someone might have the perception that getters/setters dont provide encapsulation. I think we can say that, in practice , getters/setters dont provide encapsulation, but theoretically, they do.
> In theory a getter/setter is a 'good' thing.
Yes, I agree. In theory, getters/setters are really a good thing. Thats because, according to my opinion, they are the demonstration of encapsulation concept.
> In practice it is a bad thing because it does in fact
> expose what it should be hiding.
The decision of expose or not is a choice. When you writes the code of some class, in theory you are conscious of every detail of this class, and, obviously you clearly know the purpose of this class, too. So, if the purpose of the instances of this class is to transfer data, why should the private values be hidden? DTO: Data Transfer Object, even the name of this pattern explains the pattern itself! The objective of this pattern is just... to transfer data/informations/filed values! And DTO is the most classic example of getters/setters usage. The way you use to expose that doesnt matter: you can make the fields publicly available, or you can provide getters/setters for that. Whatever. But why should the private values be hidden? If this is your objective, why not?
The fact is that, theoretically, he/she can make the choice of expose or not the private field values, or he/she can expose any value he/she want! Encapsulation guarantees this choice, this flexibility.
I think that getters/setters in practice are bad not because they expose what should be hidding. They are bad because, in practice, they always expose the private values! If they always do that, why would we need them? This is the question.
> In the first case I suspect it is considered a 'good'
> thing because the object exists in isolation. And in
> isolation the usage is limited. In practice that
> isn't true.
I didnt understand. What is isolation?
> There are three uses in practice.
> 1. Provide getter/setters on everything. The vast
> majority of these methods are not used but they exist
> 'just in case'.
> 2. Provide getter/setters on everything. The vast
> majority of these methods are used.
> 3. Provide the appropriate exposure either via
> getters/setters or public access based on design.
> There are very few getters/setters.
>
> 1 and 3 are the same except that in 1 the
> developer(s) didn't realize that their correct design
> didn't need to expose everything.
> 2 represents a bad design. In all likelyhood the
> code is procedural rather than OO.
I think I can understand you a little more now. So, I suppose that you consider the manner that, generally, the developers use getters/setters is bad. Right? Then, the problem is just this manner! It does not mean that getters/setters model doesnt follow encapsulation concept. It just means that the manner that getters/setters are used is abusively wrong. The problem is the bad developers, who think that they can get and set everything, thinking that they are designing very well, just because the fact that they are using getters/setters methods. But, personally, Ive never known this kind of bad developer/programmer. All the programmers I know use getters/setters very consciously, to expose what is really important for the application. They dont expose everything.
> > My understanding about Encapsulation:
> > When we use private fields we are preventing that
> > others access this field, right? But, more than a
> > simple field, we are controlling the way we use to
> > expose the information. We can control that
> > making the fields as private and providing and
> > interface that will be used to expose the
> > data/informations/field values. Sorry if I am
> using
> > an expression that is causing double meaning in
> your
> > minds, but when I use the term access
> control
> > I want to say that we are controlling the access
> to
> > the internal details of the class. Isnt private
> > keyword used when we want to prevent the direct
> > access to the field or to the method? I think
> > access control is a reasonable term, and it
> is
> > understandable.
>
> Yes but what does that have to do specifically with
> encapsulation and data hiding?
Sorry, I dont think that I need to explain more. Please, just read again my definition of encapsulation. The answer of your question is there. Or I simply didnt get your question. I think you are asking about my definition of encapsulation, arent you? So, just read again. Or maybe your definition of encapsulation concept is different from mine. So, please, provide me your definition, and we will be able to confront our definitions. For better clarifications.
> Again no one said that getter/setters never have any
> value.
Can I conclude that you are saying that, in some way, getters/setters are estimulating developers to abusivelly use them, even exposing what they shouldnt? So, is this your reason that you use to affirm that getters/setters dont encapsulate? Can I conclude, then, that you are saying that DTOs are being abusivelly used in a wrong way? If I am right in my conclusions about your thoughts, then, sorry, I dont agree with you.
> When I create a collection object and I decide to add
> a size() method I do so not because I want access to
> a particular data member but because I want to know
> the size of the collection.
>
> When I add getters/setters it is solely because I
> want access to a data member (and I am adding some
> convienence functionality associated with accessing
> that data.)
Then my example wasn't actually a getter. It just looks similar because it uses getWidth. Sorry for the confusion.
you cannot use encapsulation or define it in isolation from other oo principles. Encapsulation by definition means :-
encapsulation ensures that an object can be changed only through established channels (namely, the class's public methods). Each object exposes an interface those public methods, which specify how other objects may read or modify it.
Now as per encapsulation you are prohibited from exposing the member data of a class. Now how would it communicate with other classes in that case in real life? Classes do not act in isolation. That's something you cannot do, classes have couplings and dependencies, the minimum the better but they still have them, that's the nature of the beast so what is encapsulation then. That's where the idea of interface jumps in. Scott Meyers handles this issue by separating the class interface from the class implementation. So the client implementation of a class should be dependant on its interface. That's how its related to abstraction. Anytime you have to look at a class's inner implementation rather than referring to the interface you are violating the encapsulation, in that case you are not programming to the interface but through the interface and that's whats not allowed in encapsulation. Anything outside the interface implementation of the class should be declared private. This would not only secure encapsulation but also ensure that your classes are loosely coupled.
> Id say that getter/setter in practice, and
> generally, is used to provide public access to
> private data member. Although, theoretically, it is
Thats where the design goes bad, providing access is not the duty of a class but an interface any methods even getters and setters defined public outside the interface definition are a bad design, refer to my post in reply#68 for details.
> just a choice, chosen by the developer. The main
> point is that the developer has this choice. The
> developer can get or set anything he/she wants, when
> he/she uses getters/setters. Theoretically, it is a
> great flexibility. If he/she will take the advantages
> of this flexibility, well...this is other conceptual
> problem. The practice proves that 95%, or even more,
> of DTO (Data Transfer Object pattern) objects simply
> work as you say: they simply provide public access to
> a private data member, nothing else. This is my
> feeling, my opinion (that 95%). Thats why someone
> might have the perception that getters/setters donta
> provide encapsulation. I think we can say that, in
that perception is correct to some extent. gettes and setters outside interfece defintion is violation of encapsulation and would increasing coupling and dependencies, signs of a bad design.
Again refer to reply#68 for details
> you cannot use encapsulation or define it in
> isolation from other oo principles. Encapsulation by
> definition means :-
>
> encapsulation ensures that an object can be
> changed only through established channels (namely,
> the class's public methods). Each object exposes an
> interface those public methods, which specify how
> other objects may read or modify it.
>
> Now as per encapsulation you are prohibited from
> exposing the member data of a class. Now how would
> it communicate with other classes in that case in
> real life? Classes do not act in isolation. That's
> something you cannot do, classes have couplings and
> dependencies, the minimum the better but they still
> have them, that's the nature of the beast so what is
> encapsulation then. That's where the idea of
> interface jumps in. Scott Meyers handles this issue
> by separating the class interface from the class
> implementation. So the client implementation of a
> class should be dependant on its interface. That's
> how its related to abstraction. Anytime you have to
> look at a class's inner implementation rather than
> referring to the interface you are violating the
> encapsulation, in that case you are not
> programming to the interface but through the
> interface and that's whats not allowed in
> encapsulation. Anything outside the interface
> implementation of the class should be declared
> private. This would not only secure encapsulation
> but also ensure that your classes are loosely coupled.
and what would be an interface in this case?
> Fascinating thread! Can anyone recommend a text,
> preferably free, that describes good general
> practices for OOP? All I have been able to find via
> Google is either the concepts embedded inside learn
> the language books or course descriptions/syllabi
> from universities.
I am more of a books guy and I sure can recommend a few books
1) Code Complete By Steve McConnel 2nd edition
2) Refactoring by Martin Fowler
3) The GoF patterns book
these would be a good start and then you can move to
Martin Fowler's Enterprise Application Patterns and so on.
> > A getter/setter is a method whose point of
> existance
> > is to provide public access to a private data
> > member.
>
> Id say that getter/setter in practice, and
> generally, is used to provide public access to
> private data member. Although, theoretically, it is
> just a choice, chosen by the developer. The main
> point is that the developer has this choice. The
> developer can get or set anything he/she wants, when
> he/she uses getters/setters. Theoretically, it is a
> great flexibility. If he/she will take the advantages
> of this flexibility, well...this is other conceptual
> problem. The practice proves that 95%, or even more,
> of DTO (Data Transfer Object pattern) objects simply
> work as you say: they simply provide public access to
> a private data member, nothing else. This is my
> feeling, my opinion (that 95%). Thats why someone
> might have the perception that getters/setters dont
> provide encapsulation. I think we can say that, in
> practice , getters/setters dont provide
> encapsulation, but theoretically, they do.
Yep.
Although I don't consider DTOs to be "objects" in terms of OO. They are just a way to group related data members and not true objects.
>
> > In theory a getter/setter is a 'good'
> thing.
>
> Yes, I agree. In theory, getters/setters are
> really a good thing. Thats because, according to my
> opinion, they are the demonstration of encapsulation
> concept.
>
> > In practice it is a bad thing because it does in fact
> > expose what it should be hiding.
>
> The decision of expose or not is a choice. When you
> writes the code of some class, in theory you are
> conscious of every detail of this class, and,
> obviously you clearly know the purpose of this class,
> too. So, if the purpose of the instances of this
> class is to transfer data, why should the private
> values be hidden? DTO: Data Transfer Object, even the
> name of this pattern explains the pattern itself! The
> objective of this pattern is just... to transfer
> data/informations/filed values! And DTO is the most
> classic example of getters/setters usage. The way you
> use to expose that doesnt matter: you can make the
> e fields publicly available, or you can provide
> getters/setters for that. Whatever. But why should
> the private values be hidden? If this is your
> objective, why not?
Although DTO should be the primary example, I have seen usage otherwise. I have seen people suggest that every single class in a system should have setter/getters for every single private attribute with the reasoning that they are provided 'just in case'.
And certainly many people feel that a getter/setter is "better" than just making the member public because it it is "more" OO. And thus any exposure is justified without any consideration for why the exposure is needed in the first place. It is that sort of view point that I am specifically against.
>
> The fact is that, theoretically, he/she can make the
> choice of expose or not the private field values, or
> he/she can expose any value he/she want!
> Encapsulation guarantees this choice, this
> flexibility.
>
> I think that getters/setters in practice are bad not
> because they expose what should be hidding. They are
> bad because, in practice, they always expose
> the private values! If they always do that, why would
> we need them? This is the question.
>
Yep.
> > In the first case I suspect it is considered a 'good'
> > thing because the object exists in isolation. And in
> > isolation the usage is limited. In practice that
> > isn't true.
>
> I didnt understand. What is isolation?
The example class. It is presented in isolation rather than in a system. And in isolation there are no interactions. So one need not consider that a usage might be appropriate.
>
> > There are three uses in practice.
> > 1. Provide getter/setters on everything. The vast
> > majority of these methods are not used but they
> exist
> > 'just in case'.
> > 2. Provide getter/setters on everything. The vast
> > majority of these methods are used.
> > 3. Provide the appropriate exposure either via
> > getters/setters or public access based on design.
> > There are very few getters/setters.
> >
> > 1 and 3 are the same except that in 1 the
> > developer(s) didn't realize that their correct
> design
> > didn't need to expose everything.
> > 2 represents a bad design. In all likelyhood the
> > code is procedural rather than OO.
>
> I think I can understand you a little more now. So, I
> suppose that you consider the manner that,
> generally, the developers use getters/setters is bad.
> Right? Then, the problem is just this manner! It does
> not mean that getters/setters model doesnt follow
> encapsulation concept. It just means that the manner
> that getters/setters are used is abusively wrong.
That would be it.
>
> > Again no one said that getter/setters never have any
> > value.
>
> Can I conclude that you are saying that, in some way,
> getters/setters are estimulating developers to
> abusivelly use them, even exposing what they
> shouldnt?
Yes.
> So, is this your reason that you use to
> affirm that getters/setters dont encapsulate? Can I
> conclude, then, that you are saying that DTOs are
> being abusivelly used in a wrong way?
No, because I don't consider DTOs objects (as above.) At least not the way I create them.
And repeating myself again, sometimes it is appropriate and necessary to expose data. However it is done. One should have a valid reason for that in terms of objects though rather than just in terms of that they want the data.
