[Newbies] Design best practice : put state-independent
r.j.rothwell at gmail.com
Tue Mar 25 23:13:27 UTC 2008
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 doesn't
> 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 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...
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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners