Reputation
3,294
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
1 16 33
Newest
 Custodian
Impact
~202k people reached

2d
comment Why does Java require multi-steps for simply reading input?
Is this a rant in disguise, or is there an actual question that needs answering?
Apr
14
comment Does the visitor pattern violate the Liskov Substitution Principle
Is it just me or every other question on P.SE is about the LSP? It seems we're obsessed with it :P
Apr
13
comment Understanding polymorphism and interface in Java
@fizzix Yes, a.m2() won't compile in your example. Not because a doesn't "have" method m2() (it does have it, since a is an instance of B), but because you only told the compiler enough information to know it's an A. Note that if you casted a to class B, you'd be effectively telling the compiler "I assure you this a is an instance of B", and it'd let you call method m2, like this: ((B) a).m2().
Apr
13
comment As a programmer, how can I speed up my adoption and understanding of business rules?
This is a very good question to discuss with other programmers, but unfortunately it's off-topic for this Q&A site: it's both too broad (there is a lot to say about the matter) and primarily opinion-based (different people will tell you different things, essentially what works for them... how are you going to choose the "right" answer?).
Apr
13
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
@AndrewPiliser Not for EDGE, no. Absolutely nothing works for EDGE, because it effectively means "no connection" :) No amount of optimizations can compensate for that fact.
Apr
12
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
+1 Not sure why this answer has downvotes instead of upvotes plus being the accepted answer. It suggests both a way to handle the problem, plus an analysis of what the real underlying problem might be (i.e. that nobody wants to be told their code must be radically re-written).
Apr
12
comment How to deal with misconceptions about “premature optimization is the root of all evil”?
@errantlinguist In that case, it's not google.com's problem. It's a connectivity problem: nothing works on an EDGE connection. I consider the "E" symbol the same as "no connection" ;) More seriously: it wouldn't be an optimization problem, since nothing they could do at Google to improve their website would change the fact EDGE doesn't work for anything.
Apr
8
comment Why are getter and setter functions considered to be against OO design? Why they should be avoided?
@JacquesB Yes, many, but more importantly, that's not a good argument. Some features are prone to misuse and are considered bad design choices (as an example, see the infamous Billion Dollar Mistake). The widespread use of getters/setters in Java is one of them. Note that it's not that they "can be misused", but that they often are; when an error is widespread, it points to a design error in the language itself. And regardless, like it has been mentioned several times already, they are theoretically at odds with OO design (which is what this question was about).
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...