[Newbies] Design best practice : put state-independent
methodsonclass side?
David Mitchell
david.mitchell at gmail.com
Wed Mar 26 14:00:48 UTC 2008
> > 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.
More information about the Beginners
mailing list