RE: Design best practice : put state-independent methodsonclass side?

> (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
don't agree.

Ramon Leon
http://onsmalltalk.com