The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Java Design Issues
A Conversation with Ken Arnold, Part VI
by Bill Venners
October 14, 2002

Page 1 of 5  >>


Ken Arnold, the original lead architect of JavaSpaces, talks with Bill Venners about whether to prohibit subclassing, whether to use Cloneable or copy constructors, and when to use marker interfaces.

Ken Arnold has done a lot of design in his day. While at Sun Microsystems, Arnold was one of the original architects of Jini technology and the original lead architect of JavaSpaces. Prior to joining Sun, Arnold participated in the original Hewlett-Packard architectural team that designed CORBA. While at University of California, Berkeley, he created the Curses library for terminal-independent, screen-oriented programs. In Part I of this interview, which has been published in six weekly installments, Arnold explains why there's no such thing as a perfect design, suggests questions you should ask yourself when you design, and proposes the radical notion that programmers are people. In Part II, Arnold discusses the role of taste and arrogance in design, the value of other people's problems, and the virtue of simplicity. In Part III, Arnold addresses the concerns of distributed systems design, including the need to expect failure, avoid state, and plan for recovery. In Part IV, Arnold describes the basic idea of a JavaSpace, explains why fields in entries are public, why entries are passive, and how decoupling leads to reliability. In Part V, Arnold discusses the data-driven nature of JavaSpaces, how JavaSpaces lets you "throw in a grain and watch it grow," and why iteration isn't supported in the JavaSpace interface. In this sixth and final installment, Arnold discusses whether to prohibit subclassing, whether to use Cloneable or copy constructors, and when to use marker interfaces.

Prohibiting or Designing for Inheritance

Bill Venners: The book The Java Programming Language, which you coauthored with James Gosling, contains this paragraph:

Marking a method or class final is a serious restriction on the use of the class. If you make a method final, you should really intend that its behavior be completely fixed. You restrict the flexibility of your class for other programmers who might want to use it as a basis to add functionality to their code. Marking an entire class final prevents anyone else from extending your class, limiting its usefulness to others. If you make anything final, be sure you want to create these restrictions.

By contrast, in his book Effective Java, Josh Bloch suggests we should design and document classes for inheritance or prohibit inheritance, either by providing no accessible constructor or marking the class final. What is your opinion?

Ken Arnold: My take is rather different. Making something final is a radical thing to do. Marking a method final asserts that changing the method in a subclass is improper. Marking the whole class final asserts that even having a subclass is improper, because you made it impossible.

For example, an instance that many people bump into in Java is the String class. String is final. I know many people who would have no problem if all of String's methods were final, but they want to add some methods in a subclass that are relevant to manipulating Strings in their environment. However, they can't extend the notion of String in that way because String is final, and that frustrates them. I think that is a fair frustration.

You should mark things final only if you have a good reason. If you mark three classes final a year, you might be doing too much. For the most part, you don't know enough about the future to know if proper and legitimate subclasses exist.

Now you may more commonly mark methods final. In String's case, you may not want certain methods overridden under any circumstances because, let's say, security code depends on String comparison to operate in a certain way. You want the equals method to always means exactly that; therefore, you make that method final so it can't be overridden and changed. Marking methods final is still rare, but more likely than marking entire classes final.

On the other hand, many classes in the Java language core, especially among the older classes, have all sorts of protected data members. But nobody sat down and asked: If I were to subclass this, what would I need to do? My personal feeling is that the only difference between protected and public is a question of target audience. Protected is a variant of public, because anybody can access a protected member if he or she wants to, without much difficulty.

Something protected is designed for a certain set of people, for whom it is public. So I never make protected data members, for the same reason I never make public data members. The same rule applies: You don't want to expose your internals. You ask yourself: What does a subclasser need special access to? You wouldn't give that special access to other people, but subclassers should have it. And you want to design protected members carefully, because just like any public exposure, protected exposure limits you in the future. It is a contract. You can't change it tomorrow, because people won't accept it; in principle, you are wrong to change it. So I am against making things protected just because subclasses might want them. You should design your protected interface as carefully as you design your public interface. You ask the same questions: If I am a subclasser, what kinds of things will I want to affect? What kinds of things shouldn't I touch?

You can assume that people creating subclasses will invest more in understanding the superclass than those just using the public interface. So you can expose sharp edges in the protected interface you wouldn't want to expose in a public interface -- but you have to design it. You should not mark anything protected unless you design the system to be subclassed. But I wouldn't say everything should be final, unless you know it can be subclassed. That is like saying the only things you can do are the things we tell you you can do. How do you know that much about the world? Where did you get the ability to predict other people's needs?

Page 1 of 5  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use