On Tue, Mar 25, 2008 at 5:44 PM, Ramon Leon <ramon.leon@allresnet.com> 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...
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