Silly Java rules?
Kevin Barnes observes that some pretty silly rules have developed around the use of Java.
I should declare my interest at this point: I work on Java standards and IBM's Java runtimes. That said, I think some rules of thumb are useful for beginners provided that skilled programmers break the rules as necessary.
I dislike classes with numerous getter and setter methods as this is a pretty strong hint that a class is badly designed, or that the programmer would have preferred a C struct ;-). Some consider these methods inherently evil, but I wouldn't go that far.
The use of final is more interesting. In C++, const is useful in defining good interfaces and final may play a similar role in Java. But the use of final on local declarations doesn't seem to be worth the syntactic clutter.
One of the proponents (thanks for the link, Kevin) of the use of final seems more concerned about controlling subclassing. That's a more interesting point to argue as it comes back to good interface design. But I don't think there's a general rule - it depends on the circumstances. Anyone designing a Java interface needs to understand the trade-off.
Since Java enshrines 'non-final' as the default (and it's too late to change that!), beginners risk coding Java interfaces that will behave unexpectedly when subclassed. But changing the language default wouldn't enable beginners to design good interfaces. As they say "there's no substitute for understanding".
2 comments:
Surely the whole point of getter and setter methods is to allow encapsulation?
I know it is very popular to attack access methods these days, and complaints range from "just use a C struct" to "too many keystrokes".
But let us cast our minds back to those Comp Sci courses so long ago. The whole point of OO is to avoid spaghetti code. Structs lead to spaghetti code and are hard to maintain.
Also, when you subclass a class, it is _supposed_ to change the behaviour. That is the whole point of subclassing.
I don't think some of the most vocal of the pundits grok OO anymore, some of them I wonder if they ever did.
>Surely the whole point of getter and
>setter methods is to allow encapsulation?
Sometimes that's true, but not always. ;-)
Certainly getters and setters give better encapsulation than making fields of a class public or protected.
But it really depends on the abstraction that a class represents and whether encapsulation is broken by adding getters and setters.
For instance, consider a stack class which holds on to a certain amount of popped space. (Sorry for the artificial example, but it makes the point.)
Adding a getter to return the amount of popped space would break encapsulation because it would give away implementation detail. It would then be a little harder to improve the implementation without potentially impacting users of the stack.
Post a Comment