Smalltalk: How to not Design an API
I’m doing a lot of Smalltalk programming these days, and it’s great fun. The language is very powerful and flexible. However, my experience is with a bastard child of Smalltalk: Squeak. This is a complete mess because it seems like every library adds a few methods to core classes like Object and Class. For example, Squeak has a XML (sigh) library named SIXX, and its brilliant developers felt they had to add 18 (eighteen!) methods to Class. Here is the brilliant part: everything is public in Smalltalk, which means that you do not have to add a method to an object to access its instance variables.
Contrary to popular belief, everything is not a lock (in Java java.lang.Object is a lock, making almost everything a lock); keeping the number of methods to a bare minimum in core classes keeps everything simpler and easier to learn. Here is how I believe the core classes should look like:
So what about all the utility methods you normally find in these classes in both Smalltalk and Java?
They belong in utility classes. For example, everything related to regular expressions should live in a separate library. But what about reflection?
you ask. You will find the answer in Gilad’s fine paper on mirrors. I believe many of the considerations of the mirror paper apply to software engineering in general.
July 7th, 2007 at 2:31 am
I agree that the APIs of some programming languages are not what they should be alike. Of course, much of this knowledge comes with applying a language. In Java, for example, it’s only Class which is its own reflection accessor, while there are seperate reflection classes for Method, Constructor, Field, etc.
What I am not sure about, you are kind of distincting between object-classes and utility-classes, which is interesting. While objects usually define operations on themselves, utility-classes define operations on others. This sounds like utility-classes are rather operation containers (function libraries?) and no “valid” classes.
July 8th, 2007 at 2:49 am
Utility classes model real concepts just like other classes. Having objects defining all operations on them is not a litmus test for “proper” object orientation. In real life, I take my car to a mechanic to get a change of oil; I do not tell the car to change its oil. There is no natural reason to have a changeOil method on a Car object, and I shouldn’t put it there if the only reason is objects define their own operations. Similarly, regular expressions aren’t necessarily operations defined by a String class. Regular expressions are concepts themselves.
July 8th, 2007 at 8:48 am
True. Maybe, I was thinking to much of static utility classes. Classes should always only define those operations that are necessary for the purpose of its instances. Actually, not even the mechanic should implement a changeOil method, but take a Car object and a Task object that describes the process to change Oil.
Thanks.
July 9th, 2007 at 2:21 pm
That Mechanic “should” not implement changeOil is a bit too hard: when I bring my car to the mechanic, I tell him to change the oil. In effect, I pass the message “change oil” and my car along to the mechanic. Passing a message is just another way to say call a method. On the other hand, if I fill out a work order and gave that to my mechanic along with my car, you could say I pass the message “do” along with a work order (Task) and my car.
July 10th, 2007 at 2:39 am
Well, the analogy lacks a bit in general. Usually, one does not talk to the mechanic directly but some guy who will delegate the task. Or the mechanic may pick up the work order corresponding to the message “change oil”. Etc.
So, yes, “should” is too hard, as it always depends on the business requirements.
July 11th, 2007 at 10:32 am
[...] The Weblog of Peter Ahé Thoughts on language design, API design, compilers, Smalltalk, and Java technology « Smalltalk: How to not Design an API [...]