[KCP] SystemDictionary cleaning: Comments and design

Andreas Raab andreas.raab at gmx.de
Wed Jun 11 21:51:27 UTC 2003


Alexandre,

> > Right now we have
> > two such places - SystemDictionary which holds most of the 
> >"environment
> > related" utility methods and Utilities which holds most of the rest.
> > Introducing a hundred new classes all of which have one or 
> > two methods just so that they are NOT in some place isn't
> > very good design either. IMO at least.
> 
> The class SystemDictionary and Utilities are really a mess. 
> How can a class deal with VM statistic, graphical support, 
> and some network stuff? That's not OO programming.

It seems that most of you only read the last paragraph and those before, so
let me quote it for you:

"If there is a recognizable concept for a number of methods which make sense
to think about them as "attached to" a common class (system navigation for
example) then I'm all for it."

Does this answer your question?

> Such classes have too much dependencies and that's against 
> all the basic principle of OO programming. Here is a nice 
> example, why should I write Utilities pointOrNilFrom: '2,6' ? 
> IMHO, that is really absurd.

That might well be but it is worthwhile to recognize that we are dealing
with human beings here. And those often have situations where things aren't
quite clear to them yet but may become so later (the process is called
"learning"). And unless you want to force people to stick stuff into places
that are no better than Utilities it seems worthwhile to me to have a single
place where you can find all these "as yet unclassified" utility methods.

So how's that: Let's change the class comment of Utilities to state "I am a
class that holds utility methods for which no better general concept has
been found. Methods added to Utilities will regularly be refactored so using
a method still in Utilities is considered temporary and may have to be
changed once a better place for the concept has been found."

Deal?

Cheers,
  - Andreas



More information about the Squeak-dev mailing list