Interview with Ken Arnold on Design

Bill Venners writes "Artima.com recently completed publishing a six-part interview with Ken Arnold on distributed systems, JavaSpaces, and design. In Perfection and Simplicity, Ken explains why there's no such thing as a perfect design and proposes the radical notion that programmers are people. In Taste and Aesthetics, Ken discusses the role of taste and arrogance in design, the value of other people's problems, and the virtue of simplicity. In Designing Distributed Systems, Ken addresses the concerns of distributed systems design, including the need to expect failure, avoid state, and plan for recovery. In Sway with JavaSpaces, Ken describes the basic idea of a JavaSpace, illustrates how decoupling leads to reliability. In Data, Decoupling, and Iteration, Ken explains how JavaSpaces lets you "throw in a grain and watch it grow." In Java Design Issues, Ken discusses whether to prohibit subclassing, whether to use Cloneable or copy constructors, and when to use marker interfaces."

What he means by "prohibit subclassing"

[Lumpish Scholar]

Here's a partial quote from the interview:

[first quoting Arnold and Gosling:]

"Marking an entire class final prevents anyone else from extending your class, limiting its usefulness to others...." 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 ....

Here's the discussion: There are abstract classes (as per the Java keyword) and concrete classes. You can make instaces of the latter but not the former. (You can create a Porshe911 object but not a Car object.) There are also leaf classes (which no one's derived any subclasses from) and non-leave classes (which have subclasses). Java has the final keyword to force a class to be a leaf class. (For example, String is a final class; a String is a String is a String, not some sort of customized String-like object.)

So ... should all non-leaf classes be abstract, and all leaf classes be final? Or should you be able to subclass a concrete class?

It's an interesting discussion to have. I'm not committed to either side.

"you want to make illegal things impossible"

[Lumpish Scholar]

Don't give people a method that does something error-prone. Give them the method that allows them to do the subset that is not error-prone. Suppose you have a file object on which you can call open and close. You can only close an open file. You shouldn't be able to call close on the file object, because it may not be open. The open method should return something on which you can invoke close. Therefore, you can't invoke close on something you have never opened, because the only thing you can invoke close on you get from open. Now you can't express the error. So you don't have to catch the error of attempting to close an unopened file, because you can't even write that.

Very cool!

Re:"you want to make illegal things impossible"

[phr2]

But you still need to catch that exception. What if you get that open file object, close it, and then try to close it a second time?

Re:"you want to make illegal things impossible"

[Warlock48]

In part 3 (Designing Distributed Systems), Ken says "You can't solve all problems with it, but basically idempotency says that reinvoking the method will be harmless."
It's in a different context, but I'd say it's a good idea: if you try to close a file a second time, nothing happens! And that's how standard Java file-like objects work, their close() methods does nothing if the file is already closed.

Re:"you want to make illegal things impossible"

[kcrca]

I agree that making a redundant close harmless works here. But another way to state the problem is that you still have to check for "write after close" problems. Which is true -- not all illegal things can be made impossible. But when they can, it's a good thing to do.

In this case it's not so bad because any write might fail, so you have to deal with failures anyway.

C++

[GigsVT]

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?

This is an interesting point. I know a good bit of C++, but I don't often code in it. Why? Because I spend twice as much time looking up methods and classes than I do actually coding. Half the time I still later discover that I reinvented the wheel.

Re:C++

[e-Motion]

This is an interesting point. I know a good bit of C++, but I don't often code in it. Why? Because I spend twice as much time looking up methods and classes than I do actually coding. Half the time I still later discover that I reinvented the wheel.

I find your comment somewhat ironic, considering that the articles are mostly about Java, whose library dwarfs C++'s. What is your preferred language? C? Or are you suggesting that Java's library is simpler than C++'s?

A large library can be overwhelming, but it is a great tool to have at one's disposal. I learned C++ before I learned Java, and, at first, Java's mammoth library confounded me. These days, I consider it almost indispensible. I felt the same way when I transitioned from C to C++.

Re:C++

[tpv]

Not the orignal poster...

Or are you suggesting that Java's library is simpler than C++'s?
I think that's true, but I don't think it's the main reason why I prefer writing in java.

In my mind the problem with C++ is the patterns - there's too many of them.
Pass by value, pass by reference, who takes ownership of this memory, is it shared?
Difference groups of people do it a different way, and so each time you use their code, you have to work out what patterns they use, and find a way to bind them into your design.
That problem is made worse by the fact that the std library is quite small, and historically was even smaller - lots of people wrote lots of libraries and there's no common theme.

In java it's easier. Most things follow the same pattern - partly because there are less patterns to chose from (all the memory managament ones dissappear) and partly because the library is more cohesive.

A minor point

[zipwow]

In the discussion about subclassing, especially overridden methods that are called by the superclass's constructor, he says:

Although you can't [ensure the preconditions are met] with the subclass's own data, which is where things get really complex.

If its in a subclass, shouldn't its constructor have already completed by the time your superclass's constructor is executing?

-Zipwow