>From: "andrew cooke"
>Aryeh M. Friedman said:
>
> >> Setters/getters are in my "evil stuff list", because they focus on the
> >> data
> >> part of objects, not on the behavior part.
> >
> > Exspecially when people go to an extreme like using getters/setters
> > for all queries/assignments (even "private ones") for example I saw
> > someone
> > do a ctor that literally was this:
> >
> > Foo::Foo(int x, int y)
> > {
> > setX(x);
> > setY(y);
> > }
>
>this can be useful when you need to maintain some kind of additional
>condition in the class - changing x also implies something else changes.
>
>of course, it's better to avoid this by making sure the fields are
>orthogonal, but that's not always possible.
I don't know if anyone else has read "Streamlined Object Modeling" book, but nonetheless, it's an excellent book on object modeling that I find myself accessing a lot. Anyway, they use accessors for each of their variables, but state whether the getter/setter is public outside of the class or not (in Java, this means defining as protected, package private, private, or public...In Smalltalk, it's a matter of putting a comment in that says that this method is private or public). I think making accessors all public to outside classes is a bad idea. I think you should only make public what you need to. Now, there are some cool things you can do wtih setters like run business rules to verify that the object can be set into myself. I also have special setters for collections like addToxxx and removeFromxxx so that 1) I can use reflection like on a JavaBean and 2) run business rules to make sure the object can be added. I mentioned "Streamlined Object Modeling" because they have a very nice write up about how to use getters/setters and collection setter methods and how to deal with business rules and verification in your objects.
No comments:
Post a Comment