On 5/10/06, Sean Corfield <[EMAIL PROTECTED]> wrote:
You need to test against the CVS version - it's *very* different to 0.5.0.
I'll plug it in today sometime.
I don't think that is very good practice. I think you *should* have an explicit init() in each of the derived classes (that just calls super.init() and passes the arguments up the chain).
Polymorphism is one of the greatest powers of OO, why not leverage it. CF's not Java, and while rigor would be nice in a lot of cases, without backing support from the language itself (or at least tooling), artificial rigor is troublesome. To each their own, of course, but I can't imagine that I'm the only one that uses inheritance for the init() method. In fact, I wouldn't be surprised that of the cases where an inherited init() method is possible (i.e. superclass and subclass have the same signature), the split of developer preference is towards polymorphism.
You talked about coupling yet, your derived classes are already tightly coupled to the base class - inheritance is the tightest possible coupling there is in OO design!
As I said before, I'm not talking about the coupling of the classes - I'm aware they're tightly coupled. I'm talking about the need to copy and past code from superclass to subclass, and having to manually maintain that code over time with no help except runtime errors.
Whatever initializes your classes is tightly coupled to the constructor API - it doesn't matter whether it is inherited or not, the coupling is to the constructor API of the class. By having an explicit init() in derived classes, you can actually protect users of your classes from changes to the base class because you control the construction API.
How often will you change the constructor API of a superclass, but a subclass (which IS-A) won't have to change? When I'm doing Java and refactor a constructor, the next step is to spin through the collection of new compiler errors and go change all the subclasses that are now making an incorrect super() call. CF lacks the toolset to make that a feasible operations model (you only get runtime errors, and if you have optional parameters - because there isnt' method overloading - ). In Java, of course, you can sometimes avoid that step by deprecating the current constructor and adding a new one. You can accomplish the same thing with CF to some extent by using optional parameters, but that gets really messy, really fast. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
