Sponsored Link •
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
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,
lookup service API. I don't remember the number of methods it has, but it is comparable
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
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.