Comments on: Smalltalk: How to not Design an API

By: The Weblog of Peter Ahé » Blog Archive » Correction: Instance Variables are not Public in Smalltalk

Wed, 11 Jul 2007 17:32:01 +0000

[...] The Weblog of Peter Ahé Thoughts on language design, API design, compilers, Smalltalk, and Java technology « Smalltalk: How to not Design an API [...]

By: Stefan Schulz

Stefan Schulz — Tue, 10 Jul 2007 09:39:05 +0000

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.

By: Peter Ahé

Peter Ahé — Mon, 09 Jul 2007 21:21:15 +0000

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.

By: Stefan Schulz

Stefan Schulz — Sun, 08 Jul 2007 15:48:58 +0000

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.

By: Peter Ahé

Peter Ahé — Sun, 08 Jul 2007 09:49:41 +0000

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.

By: Stefan Schulz

Stefan Schulz — Sat, 07 Jul 2007 09:31:35 +0000

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.