[MCP] [Q] Methods not used-Keep Them!

John W. Sarkela sarkela at sbcglobal.net
Fri Feb 14 15:42:06 UTC 2003


Hi All,

[...]
>
> I think only for producing a minimal runtime-image you can talk of
> unused things. Squeak is a framework and there have to be methods
> which are not used by itself. Think of any other framework where the
> API are functions for the application programmer and are not written by
> calling themselves as it is characteristic for Smalltalk. Because they
> are all 'unused' they would have to go all!

I must disagree with this point of view. When I think of a framework,
I think of a collection of central classes whose principal 
responsibility
is the coordination of an activity. The actual work is the 
responsibility
of collaborator classes which do the actual work that is coordinated
by the central classes. A well designed framework will *have* either
abstract or concrete classes for these collaborators to use in various
applications of this framework. Thus, even in a framework, all the
key methods should *have* senders in the image.

>
> If I had to choose between remove all and leave all I would opt for
> the latter. To make the right selection in between, requires to have
> extensive knowledge of Morphic, which I certainly have not.
>

In my experience, the most important coding activity (in dynamic
environments like Smalltalk) is the phase that I refer to as "uncoding".
It is after the functionality is present in an implementation that the
developers have the opportunity to crystallize their understanding
of the collaborations that fulfill the user's intent via the activity of
refactoring. I would highly recommend reading Kent Beck's
compilation of "Smalltalk Best Programming Practices." In this
book he has compiled the best gems of some of the best
practitioners of our craft. Best of all, there are concrete examples
of refactoring practices that reveal intent and operation of
object collaborations. My rule of thumb is that if there are methods
attached to an object whose intent and purpose is unclear,
then I am not finished with development.

> I think many methods in a class is no big problem, if they are
> categorized properly, it is more many classes. Maybe the key for a
> better Morphic is to merge classes with similar functionality and to
> bring down their whole number by composition, while extending
> flexibility, functionality and usability ( example: LayoutPolicy added
> by Andreas Raab to Morphic ). But this requires to have at first some
> ingenious ideas what common character in what areas of subclasses
> exist to be extracted and made available by means of composition. This
> is certainly a difficult task, for which it needs a real expert in
> Morphic. I can't help but I think it would be nice if the originators
> of Morphic could be convinced that their help is needed.

The problem with many methods in a class is that the responsibilities
of the class become dilute. Comprehensibility is a consequence
of clarity and economy of expression. Categorization of methods
will not help with messages like #altSpecialCursor3, 
#moveWithPenDownByRAA: .
Perhaps they are useful, but the message selectors are not particularly
revealing. Our goal in designing patterns of messaging is to be
unambiguous, to reveal the intent of the message, not the implementation
of the method.

Many methods in a class is an opportunity to factor the monolithic
behavior into a message coordinated collaboration of objects with
more clearly focused responsibilities. For example, morphs could
directly implement all of their layout responsibiities, or they could
instead dispatch to an object that is an "expert" in layout. It would
seem to me the goal in MCP is to reveal the different responsibilities
of a morph and to introduce into the implementation a factoring
of these responsibilities into communities of collaborators who
hold onto the majority of the methods that do the actual work.
Your example of layout is to me an argument to remove *more*
methods from Morph and move them into smaller classes with
more focused responsibility. This really isn't a difficult task.

1. Have Best Programming Practices by your side
2. find the classes with the most methods
3. organize those methods by clustering responsibilities
	that have a strong cohesion or affinity
4. use those responsibility clusters to suggest new classes
5. name those classes to reflect the more clearly focused
	responsibility
6. in the process, rename message selectors to more
	accurately represent the intent of the message
	in the context of the receiver.

In general, you will experience a small explosion of methods
and classes followed by an implosion based upon the more
reusable focused classes.

Just my quatre sous.

Cheers,
:-}> John Sarkela
[|] Knight of the Square Bracket



More information about the Squeak-dev mailing list