[Newbies] Design best practice : put state-independent methodsonclass side?

stephane ducasse stephane.ducasse at free.fr
Fri Mar 28 06:41:30 UTC 2008


Hi ramon

I agree with you. Now just without reading the complete thread, and  
for more complex situations
here is my guideline to use singleton:
I use one when I need one object "at a time" and not a single access  
point.

Often people confuse time and access. If you can get rid of a  
singleton just by adding an iv to you domain
and adding a reference to point to your "singleton" then it was not a  
singleton but a global object access.
Is it difficult to write that in a mail, a good singleton is a object  
representing really the fact that you
cannot have two objects of the same class at the same time.
Stef



On Mar 25, 2008, at 10:44 PM, Ramon Leon wrote:

>> (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
>
> _______________________________________________
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>



More information about the Beginners mailing list