 |
|
 |
 |
|
|
 Editor's Daily BlogThe Evil UmpirePosted by daniel on September 09, 2003 at 07:01 AM | Comments (4) Allen Holub has found himself writing an "is evil" series. Holub has long provided advice in terms that those that agree would characterize as "clear and concise" and those that disagree would characterize as "strongly worded." Past targets have included thread abuse, and the In Holub's JavaWorld article Why getter and setter methods are evil he argues that "they are not particularly object oriented (OO). In fact, they can damage your code's maintainability." One problem is that getters violate data abstraction. [T]here might be 1,000 calls to a getX() method in your program, and each call assumes that the return value is of a particular type. You might store getX() 's return value in a local variable, for example, and that variable type must match the return-value type. If you need to change the way the object is implemented in such a way that the type of X changes, you're in deep trouble. Holub suggests that you examine what drove you to use a getter in the first place. To reduce the number of accessors, he advises, "Don't ask for the information you need to do the work; ask the object that has the information to do the work for you." There are times that a getter is appropriate - but Holub doesn't consider these getters to be accessors. A getIdentity() method can also work, of course, provided it returns an object that implements the Identity interface. This interface must include a drawYourself() (or give-me-a- JComponent -that-represents-your-identity) method. Though getIdentity starts with "get," it's not an accessor because it doesn't just return a field. It returns a complex object that has reasonable behavior. Even when I have an Identity object, I still have no idea how an identity is represented internally. You wouldn't think of a factory method as an accessor. You probably also wouldn't think of the get method for a Singleton as an accessor - but Holub probably has an article on deck titled "Why Singletons are evil". Holub considers the getX() setX() convention in JavaBeans. First he points out that you can create JavaBeans without getters and setters. Second, he argues Accessors were created solely as a way to tag certain properties so a UI-builder program or equivalent could identify them. You aren't supposed to call these methods yourself. They exist for an automated tool to use. This tool uses the introspection APIs in the Class class to find the methods and extrapolate the existence of certain properties from the method names. In practice, this introspection-based idiom hasn't worked out. It's made the code vastly too complicated and procedural. Programmers who don't understand data abstraction actually call the accessors, and as a consequence, the code is less maintainable. For this reason, a metadata feature will be incorporated into Java 1.5 (due in mid 2004). In the Also today section we also link Andy Lester's essay The computer that cried "Wolf!". Lester begins with a list of the warnings we ignore in everyday life and then moves on to our computer habits that need to be reexamined. His advice is simple - don't add to your work-related mental clutter. "Deal with every problem. Don't brush the problem aside by making a mental note to deal with it later. That method doesn't scale. In fact, NOTHING that relies on a single person scales. Make the computer do its work." In today's featured Weblogs java.net community manager John Bobowicz recommends Socializing development tools by integrating "social software, like weblogs, wikis, RSS feeds, Instant Messangers, etc, into the development environment." The talkback already includes objections to this tendency towards "Kitchen-sink apps." Jimothy suggests that "we should instead focus on making applications easier to integrate with one another." From the Java Today News Page, news editor Steve Mallett, has gathered the following News Headlines .
| |
 java.net RSS Feeds
|
