Reputation
3,739
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
1 18 34
Newest
 Guru
Impact
~205k people reached

Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB Finally, a nitpick: it's not true that in my example "it would be as bad whether [the change] happened through any other reason". The fact is that setters as used in Java provide uncontrolled access. Without the setter, access is limited to the instance -- which the class author knows how to handle responsibly. With the setter, access is granted to the caller, who may or may not know about sensitive details... and often doesn't!... which is how Java pitfalls are born :)
Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB A different, unrelated problem with getters/setters as used in Java is that they break the "atomicity" of the construction of valid objects. When you build (or update) an object by using setters, you often break its invariant. In principle it's better to only build valid objects using constructors, not by changing them using setters. In practice, this almost never happens with Java (and intrusive frameworks like Hibernate are partly to blame). The overall pattern that emerges is that getters/setters are evil for multiple reasons!
Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB In this case, yes, but I don't want you to focus on this example alone. Java is littered with this kind of pitfalls, in many cases encouraged by a proliferation of direct-access getters & setters. It's common enough that the overall lesson is: direct access to internal fields, which is almost always the case in Java, is an anti-pattern that leads to errors. This, of course, aside from the fact I've mentioned many times already, that it's against OOP principles. So getters/setters are evil for multiple reasons, some practical, some theoretical :)
Apr
7
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB True, I phrased it poorly. It doesn't exactly break encapsulation in theory (though it does in practice, since the vast majority of getters directly expose mutable fields in Java. This is so common, novices may not even know other uses. The client may not care, but if they accidentally change the field, behavior may be unexpectedly broken. An example of accidentally breaking behavior is changing fields used to compute a hash code for an instance stored in a HashMap). And regardless of encapsulation, it definitely breaks principles from the OO paradigm (again, "Tell, Don't Ask").
Apr
6
comment Mutable objects - setters and getters
(I agree that clone is generally broken, which is why Effective Java recommends not using it).
Apr
6
comment Mutable objects - setters and getters
This doesn't answer the question. Your two alternatives are only cosmetically different. I think the OP is talking about defensive copying, so that if MyOtherClass is mutable, the client code cannot pass it to an instance of MyClass (either with a setter or the constructor, like in your example), and then mutate outside said instance.
Apr
6
revised Mutable objects - setters and getters
code formatting
Apr
6
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@duffymo I disagree. It has changed how I and many people write Java, and it (possibly) also pushed people to better languages.
Apr
5
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@BryanOakley Agreed about the question not being about Java. The referenced article is, however (and do purer OO languages such as Smalltalk use getters/setters this way, anyway? Honest question here) If you work with Java, you'll agree with me this is how getters & setters are used in practice, common enough that we cannot argue it's just "bad programmers" that do it ;) Frameworks like Hibernate make this problem even worse.
Apr
5
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB That could be argued, yes :P But more seriously, I think many of its features and the style of programming they suggest (if not directly enforce) go against OOP principles. Then again, I'm not married to OOP, but regardless of the paradigm I don't think Java as usually written leads to good, clean code. Of course, good programmers will use Java in clean ways, but what about the average programmer?
Apr
5
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
The other argument is that getting things is not the right design in OOP (the famous "Tell, don't ask" principle). But I won't press this, since almost nothing in Java is true OOP, but a hybrid of procedural+OO which was born with C++ and popularized with Java, I guess.
Apr
5
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
I think the article has a very good point. In practice, almost all uses of getters/setters in Java directly expose private fields. They allow you to modify the internals of a class in indirect ways, and also allow you to break invariants by constructing invalid objects. Special care may be taken to avoid these situations (defensive copying, verification of invariants before each operation), but in practice this is never done, which makes the widespread use of getters/setters evil. Some frameworks such as Hibernate need this to work, which makes the situation inescapable in Java...
Apr
5
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@BryanOakley In practice, however, getters/setters in languages such as Java directly map to private fields almost 99% of the time. Which is why they break encapsulation and stray from the spirit of OOP. Now, you may argue "but that's bad programming", but I don't know if I'm convinced... are you going to argue almost all Java programs are badly written?
Mar
31
comment Mutable objects - setters and getters
In Java, clone is seldom a good idea :)
Mar
31
answered How to write testcases for a piece of logic?
Mar
31
comment How to write testcases for a piece of logic?
@MiguelvandeLaar I think the question is about how to make sure you're writing all relevant test cases for any unit under test. The exact logic is not relevant for the question. Of course, the answer to this might disappoint Yashdeep :)
Mar
31
comment How to write testcases for a piece of logic?
Elaborating on what @BarryTheHatchet said, there are techniques to partition the problem space (like Equivalence Class Testing) in order to write tests that cover all (or most) relevant cases.
Mar
23
comment How much pair programming is ideal?
@JörgWMittag Sounds like a recipe for a highly stressful work environment for the many introverts doing software development...
Mar
23
comment How much pair programming is ideal?
@JeffO Not necessarily. For introverts, the time spent programming alone is refreshing and pleasing and lets them get in "the zone", and it's also probably why the got in programming in the first place. Doing this mostly with another person watching over your shoulder, constantly talking and discussing things, is highly stressful.
Mar
23
comment Why do so few languages with a variable-type 'operator' exist?
Not sure why people are getting fixated on overloading. The original question isn't about overloading. It looks to me to be about operators as first-class values. In order to write $operator1 = + and then use it an expression you don't need to use operator overloading at all!