[Prev][Next][Index][Thread]

Re: SICP & the Dumbing Down of American Comp Sci

Patrick Logan <patrick@c837917-a.potlnd1.or.home.com> writes:

> : This doesn't make a whole lot of sense in the Dylan (or CLOS) world,
> : where objects are _not_ collections of functions. The purpose of
> : objects is to capture state.
> You are right, Andreas. The concepts shift a bit for those languages
> that have multi-argument dispatch, and I am not very experienced using
> them. 
> 
> But I wonder how much the principles really change? A function is

I've spent the last days going through the literature to find a
discussion of that issue. But all the books on OO design I've seen
base their design methodology on the assumption that methods "belong"
to classes, which in Dylan they don't. The prime example is UML, which
isn't even capable of expressing multi-argument dispatch.

> going to be more maintainable the less it depends on gratuitous state,
> and more maintainable the more it relies on abstractions. Can you
> elaborate? What are the principles of good design for Dylan, CLOS,
> etc.?

That's hard to say. There's almost nothing published on that issue,
any my own experience is so limited that I can only give anecdotical
evidence.

Basically design for those languages should focus on what your objects
(in the sense of aggregated state) are and what you want to do with
them (which gives generic functions). So instead of focusing on the
objects and just treating the methods of that object as a detail of
that object, you treat generic functions as entities in their own
right.

This doesn't contradict abstraction. In objects, the abstraction is
represented through inheritance (so if I look at the state of an
object, I'm ignoring the bits of that state which are not interesting
to me by looking at the right level in the inheritance tree), in
generic functions, it is represented by the domains of the methods of
that function.

So for instance when designing a program to do arithmetics, you
abstract look at the problem is that you have classes representing
numbers, and at generic functions representing the arithmetic
operations on that numbers. You can now go on and flesh out that
abstract sketch by building an inheritance tree of your concrete types
of numbers (number <- complex <- real <- rational <- integer for
example), and concrete problem domains for the functions (for
instance, to add an integer to a real, convert the integer to a real
and pass up to the function adding two reals).

I look at multimethods of OO languages as a step in the direction of
functional languages: objects provide a good mechanism for
abstraction, but functions are design entities in their own right.

Andreas

-- 
"We should be willing to look at the source code we produce not as the
end product of a more interesting process, but as an artifact in its
own right. It should look good stuck up on the wall."
 -- http://www.ftech.net/~honeyg/progstone/progstone.html
Follow-Ups: