[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