Advertisement

Bill Venners: One thing that impresses me about the JavaSpace interface is that it has only seven methods. It is very simple, and yet I can do a lot with those seven methods. How did you achieve an interface design that was both simple and powerful?

Ken Arnold: With JavaSpaces, in particular, we had the great of advantage of leveraging off of the Linda work. We started with Linda's simple design as a launching point. It was easy to see that we didn't need to do X, Y, Z, because they could be done on top of the API. Maybe someone would want to write an API that does those things on top of JavaSpaces, but those things didn't need to be in the JavaSpace interface.

There is an important distinction between, "What does this tool do well?" and, "What can you write that uses this tool to do something else well?" When I design, I try to make each actor within the design—each class or interface, for example—do one thing right. I also try to never couple what isn't intrinsically coupled. This is a general design principle.

For example, look at what happens in, say, ServiceRegistrar, Jini's lookup service API. I don't remember the number of methods it has, but it is comparable to the JavaSpace interface, maybe ten methods. And the Jini group didn't have other work, except in principle, to reference. But ServiceRegistrar comes from that same design principle. RMI is another example. It is relatively simple to write an RMI [remote method invocation] system compared to the traditional CORBA RPC [remote procedure call] systems. I think that comes from focusing on what the user needs to do, rather than what the user might want to do.

Many people approach designs by asking, "What might the user want to do?" If you start with that question, the set of answers is infinite. You end up with interfaces that have 80 or 90 methods, or 50 or 60 interacting classes. Look at Swing's JComponent class, for example. It has well over 200 methods. JButton, as a JComponent subclass, inherits those methods. But someone dealing with a button cares about five of those 200-plus methods most of the time. The other methods are interesting in odd cases, so they should be set aside somewhere. But they're all in there together and you don't know what to touch.

There is a phenomenon I call surface area of design, which is what you must understand about a design to know which part you care about. Does the fact that there are more than 200 methods mean anything to the setText() method? You must know something about those 200 methods to know the answer to that question. You have to know what to ignore. Many people say they don't need to look at all those other methods. But you do need to know if they will interact with the methods you do care about. The problem is you need to know enough about those other methods to know you don't need to understand them.