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

>  >  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.
>
I'll have to try it with a real example (like make PWS support
multiple apps) before I change my practice.

>
>  >  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.

Singleton-ness is quite easy to code (and with class-instance
variables can often be coded once and inherited). So it isn't worth it
to me to mix-in my new object along with the class creation stuff from
Behavior. My favorite superclass is Object (or my own, domain-specific
superclass).

Do one thing and do it well is a great way to tease apart and find new
objects. When the real world gives me a new problem, time for a new
object. Object-oriented programming, after all.

You can do stateless, functional programming in Smalltalk. Some of the
most beautiful parts of Smalltalk use a functional approach.

But loading a bunch of class side utility methods on some stateless
Class doesn't feel like good object-oriented design.