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
What's wrong with keeping them instance-side?
On Tue, Mar 25, 2008 at 5:41 PM, itsme213 itsme213@hotmail.com wrote:
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
"Marcin Tustin" mm3@zepler.net wrote in message
What's wrong with keeping them instance-side?
I need similar functionality in other classes, not related by inheritance (unless I push things really high where they do not below). MI or traits might be options.
Sophie
I'm guessing you like that the class methods can be invoked easily from the class name. What you want is a well known object.
I try to do all my work on the instance side. That's where most of the objects are.
I wouldn't use a class object just to create a well known object. I'd probably start with a Singleton and work from there.
You can see drawbacks and alternatives to Singleton at c2.com:
http://c2.com/cgi/wiki?SingletonPattern
On Tue, Mar 25, 2008 at 12:41 PM, itsme213 itsme213@hotmail.com wrote:
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
I'm guessing you like that the class methods can be invoked easily from the class name. What you want is a well known object.
Like a class?
I wouldn't use a class object just to create a well known object. I'd probably start with a Singleton and work from there.
Like a class? Classes are singletons, what do you have against using them as such?
Ramon Leon http://onsmalltalk.com
"Ramon Leon" ramon.leon@allresnet.com wrote
Like a class? Classes are singletons, what do you have against using them as such?
That's my feeling too, in general.
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
- Sophie
On Tue, Mar 25, 2008 at 5:51 PM, itsme213 itsme213@hotmail.com wrote:
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
My gut reaction is that you are missing an abstraction. I can't tell for sure, because you don't give enough details. Why don't you put this code in the class of the ivars? Maybe the ivars are integers or strings, and they should be a value object. Unless you explain more about the problem domain, there is no way for me to tell.
-Ralph
beginners@lists.squeakfoundation.org
-
David Mitchell -
itsme213 -
Marcin Tustin -
Ralph Johnson -
Ramon Leon