Anonymous
Unregistered
|
|
The last I knew of Holub was working at Berkely, and whenever I read one of his articles I'm reminded of Captain Kirk's explanation of Spock's strange behavior in Star Trek IV: "I think he did a little too much LDS at Berkeley."
In all seriousness, I'm amazed that Holub still has enough credibility in the industry that JavaWorld will print his articles and APress apparently is going to publish a title of his. I mean, this comes down to one of those "is the whole world crazy or am I?" type scenarios: either Holub is right and virtually every other authority on OO programming is wrong, or Holub is wrong and they're right. Sometimes I wonder if he's really just making statements like this ("getters and setters are evil") to be controversial and grab attention, but most of the time I just think he really is that goofy.
We have countless of examples of projects / systems that were and are successful (the Java source code itself being one) using OO concepts that are contrary to what Holub advocates. In other words, most of us has been successful doing what he says we shouldn't do and what he claims won't work well. My question is this: can Holub (or anyone else) show us a non-trivial example of a system / project that was built using the approach he suggests and which isn't a maintenance nightmare? The fact that I haven't seen one doesn't prove it can't be done, but let's just say that I'm skeptical, and until you see one yourself, you should be too.
|
Allen Holub
Unregistered
|
|
There are various measures of success. For example "on time," "within budget," "useable," "maintainable," "widely used," "fully featured," and so forth. Often these measures are at oods. For example, if time to market is paramount, the code is often less maintainable. No probelm with this, of course. As I've said elsewhere, design is a series of trade offs.
These articles are expressly addressing the "success" criterion of maintainability: your code will be easier to modify and maintain if you encapsulate implementation. Indiscriminate use of accessors often violate this encapsulation.
I have no problem with your trading off maintainablity for some other criterion. My main point, however, is that you must understand the issues in order to make an informed decision. It's unprofessional, bordering on irresponsible, to use (or not use) a design element like getters and setters without fully understanding the ramifications of both choices. Given this understanding, you're able to make a choice that is intelligent in the context of your specific project and its goals.
-Allen
|
Anonymous
Unregistered
|
|
was there an answer to the OPs question in all of that?
|
Allen Holub
Unregistered
|
|
The answer to his question is that he should reread the article. The poster seems has ignored the parts of the article that talk about when accessors and mutators are reasonable, and also igored the parts of the article that discusses the fact that most of the getter/setter methods found in code are easily eliminated simply by rethinking the messaging system (which you can do by following generally accepted practices in the OO-design process), and finally he has ignored the issue that exposing implementation damages maintenance. It's as if he is commenting on the title, not the article.
So let's start over with basic principles:
1. Exposing implementation harms maintainability.
2. If an accessor exposes implemenation, it will make
the code harder to maintain.
3. Maintainability is a continuum, and you decide where you
want your program to be on that continuum.
4. By keeping the design process in the problem domain as
long as possible, you tend to design messaging systems
that don't use getters and setters because these issues
don't come up in the problem domain.
The examples cited in the earlier post (the Java libraries, for example), are great examples of how you need to compromise on the maintenance continuum, and are also examples of the exceptions to the rule that I discussed in the original article. The authors of the Java packages hid as much implementation as they could, given the fact that the libraries were both completly generic and also on the produdural boundary layer of the program.
|
Anonymous
Unregistered
|
|
In other words, no, you can't provide any examples like those requested by the OP.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
