[Newbies] Design best practice : put state-independent
ramon.leon at allresnet.com
Tue Mar 25 21:44:31 UTC 2008
> (forgot to copy the list)
> Classes are certainly well known, but not the only way to get
> a well known object.
> My pragmatic issue with using class side methods for
> Singletons is that it is a bunch of work to refactor the
> class side behavior to instance side later. Look at the
> original PWS server for a squeak specific example.
Maybe it used to be, but it's a simple refactoring at the moment, refactor
method >> move to instance side. Secondly, I'll worry about later... later,
i.e. YAGNI, classes are nice singletons and it seems like useless work to
manually implement a singleton when singleton is a built in feature.
> My design issue is that classes are for making instances
> (technically for defining behavior of instances). Making
> them the building block of the program means that I'm giving
> them extra responsibility. I like to keep the responsibility
> list as small as possible.
Classes are objects too, just because most classes build instances doesn't
mean they all have to. You might not want a class doing both, but I see no
reason it can't do one *or* the other. Serving as a singleton works well
when it's needed and keeps code simple. Saying a class should only create
instances seems a rather arbitrary restriction to place upon your designs.
> (Someone walked off with my Design Patterns Smalltalk
> Companion, which wrote about these issues better than I can.)
I'd love to see the arguments if you do recall them because so far, I just
More information about the Beginners