Design best practice : put state-independent methods on class side?

> I have some methods that currently refer to iVars, called from other methods
>  of the same class. I need similar functionality in other classes, not
>  related by inheritance, and want to keep it DRY.
>
>  If I move the iVar references into explicit method args they can be easily
>  re-located and shared.
>
>  Is it then good or bad practice to take a such collection of related
>  state-independent methods (they don't depend on any iVar) and put them on
>  the class-side of some suitable class?
>
>  My options and concerns:
>  - I could move them up the hierarchy on the instance side but sometimes hit
>  single inheritance limits
>  - I could use traits for these but am unclear about the future of traits in
>  Squeak
>  - I can put on the class side and call easily from instance-side methods,
>  but is this OK practice?
>
>  Thanks,
>
>  Sophie
>
>
>
>  _______________________________________________
>  Beginners mailing list
>  [hidden email]
>  http://lists.squeakfoundation.org/mailman/listinfo/beginners
>

>    On Tue, Mar 25, 2008 at 5:44 PM, Ramon Leon <[hidden email]>
>    wrote:
>
>      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.
>
>    
>    As a beginner who is finally starting to do some useful [Smalltalk] work
>    in a Healthcare organization, I am finding this conversation very
>    interesting because I write a lot of "utility" code...mostly data
>    "pre-processing" before it goes to the Warehouse, the Reporting engine, or
>    to files to go out the door for required reporting to other organizations.
>    
>    Should I consider something more than just "XXFileProcessor file: aFile"
>    if it will only ever run on one file that shows up in a directory once a
>    day and the whole point is that there is only ONE processor?
>    Just interested, because in such "utility" cases I end up with all my
>    helper methods on the class side and wonder to myself, "is this wrong?"
>    because it feels very similar to writing subroutines in any other
>    language...

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

>  Is my specific usage style OK -- many instance methods from many classes
>  calling shared state-less methods from a common class? Or does it have some
>  kind of code smell? Any thought on whether traits (simply mixing them in on
>  the instance side) would be a preferred approach to this?
>
>  Foo>>m1
>   Library doX: iVar1 with: iVar2
>
>  Foo>>m2
>   Library doZ: iVar2
>
>  Bar>>m3
>   Library doX: iVar7 with: ivar8
>
>  Library class>>doX: anX with: aY
>
>  Library class>>doZ: aZ

>> (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
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners
>