I'm fascinated by your post. But I would be helped a bit by an example. Do you have a simple one that wouldn't be too big a pain to post?

< rbg > sure I have an example, but I'm not so sure how simple it is. But I'll give this a shot.

Original Assignment - write reuseable code for generating annual rate packages.

Background - a rate package is a collection of reports for a customer-like entity (aka "Provider"). Each Provider's rate package is going to depend on what type of provider they are, how long they've been in the program, and other provider-specific details.

1st try - I created a class based off of custom that took parameters from a wrapper for an individual provider. This class had oodles of method code: simple validation of provider, print generic cover letter report, collect data for report1, print report1, collect data for report2, print report 2, ect.

Result - worked great for initial need & I generated a big old stack of rate packages. But... a few days later, an unexpected need/change raised its head. "Lets only generated a subset of rate packages for providers that are not yaddayaddayadda". (sigh, 'why didn't you tell me we'd need that to begin with?')

2nd try - following my option C) approach in my post to Geo, I took 3 steps back in order to go 1 step forward. I ripped my original custom class apart, created a generic superclass that only handled the firing off of a method when needed, the simple validation, and the print report methods. Then I created a subclass of that to generate all rate packages, and another subclass to generate the subset of rate packages.

Result - worked great, was real proud of myself. ('hey this oop shit aint so hard after all' ;) ) But... A month later guess what, now I need to do the same original (1st try) assignment but for quarterly rate pakages instead of annual. (sigh, 'I didnt know we printed quarterlies too?')

3rd Try - so ok, quarterly packages have a whole different set of initial validation, and the same reports are generated but certain bands don't get printed, and some reports not printed at all. Gee whiz, my cure-all abstract parent class isn't going to cut it and I'm going to create an inheritance nightmare if I follow suit with my 2nd Try. Alright, let's rip it all apart again :) This time my abstract parent class became concrete and it instantiates an aggregate oValidateProvider object that's specific to whether it's an annual run or quarterly run. Plus my 2nd try subclasses became separate custom classes that are instanced into my oValidateProvider pointer and they tell the controlling object how-to-print, what-to-print, and when-to-print.

Additional - several other small assignments came up to tweak the way both annual and quarterly packages get generated and I didn't have to rewrite anything! (ya know - the more you do the more they want kind-of-thang). My 3rd Try has so far proven to be very flexible, and the other unexpected needs that popped up since only required minor extensions (add a property here, change a validation there) and I was still good-to-go.


>Did you read the article "ECM in Color" that DF pointed out a while back (www.oi.com/ecm.htm is the link)?

No I missed that - but I'm surfing on over now :)