[Newbies] Design best practice : put state-independent
tapplek at gmail.com
Wed Mar 26 00:02:34 UTC 2008
On Tue, Mar 25, 2008 at 07:13:27PM -0400, Rob Rothwell wrote:
> On Tue, Mar 25, 2008 at 5:44 PM, Ramon Leon <ramon.leon at allresnet.com>
> Classes are objects too, just because most classes build instances
> mean they all have to. You might not want a class doing both, but I see
> reason it can't do one *or* the other. Serving as a singleton works
> when it's needed and keeps code simple. Saying a class should only
> instances seems a rather arbitrary restriction to place upon your
> 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
If it works, cool. You can always refactor later
> On that note, isn't that sort of all traits really are? A subroutine not
> attached to any particular object? But with no access to object data
> short of resorting to things like self classPool at: #Var, which I suppose
> defeats the point, but darn it, I keep running into situations where
> multiple inheritence would be great!
> Rob Rothwell
No. Traits are units of behavior that can be shared among
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
Matthew Fulmer -- http://mtfulmer.wordpress.com/
More information about the Beginners