On Mon, Dec 1, 2008 at 1:15 PM, Bob Tarling <[EMAIL PROTECTED]> wrote:
> How about using the template pattern,defining in the base constructor > what things must happen in what order. Someone extending the a Fig > should then never have to do anything in the constructor apart from > call the appropriate super constructor. That's a good idea, but defining the template is going to require a holistic view of the entire system which is not something I'm confident that I have. Additionally, doing this in an incremental fashion will probably require defining a new set of methods with well defining semantics. Currently the way initialization is done is "Oh, it looks like there's some initialization stuff in setOwner(), lets toss ours in there too." The only way that a super constructor would be able to call setOwner() today would be to refactor the entire set of Figs all at the same time -- which isn't likely to happen. My current plan of attack is to have the old 0-arg constructors to continue to call whatever methods they call, but to have the new constructors only call private or super methods, but I'm willing to look at a template approach if someone is confident that they can come up with the right template along with a partitioning and ordering of related initialization work. I've done probably 1/3 to 1/2 the figs so far and I haven't run into anything that seems insoluable. What I should probably do is commit the work for a Use Case diagram so that people can get a look at some concrete code, rather than lots of verbiage. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
