Hi Richard, I'm quite happy there's someone else out there that sees things like I do.
> Here's a couple more advantages of using delegation for the > *Impl classes: > > - If we don't need an *Impl class (i.e. if there are no > business methods that need to be handcoded), we don't > generate them. This has the potential to > eliminate a lot of bloat, since for the vast majority of > <<Entity>> classes there is no real need for an *Impl class. That is definitely a worthwhile advantage. It would be easily done in the <<Entity>> classes, but is there a way to have the AndroMDA generator skip generation of certain classes based on certain criteria? For example, if there are no business methods declared on an Entity, skip the generation of a Delegate interface and delegate concrete class. I haven't seen this functionality yet. Anyone know? > - We can make the *Impl class concrete even for entities > (can't do that in the current version, because the CMP/CMR > accessors have to be abstract). Even better, we can make > all *Impl classes implement a generated interface that > decalres the business methods, and have the compiler catch > changes in the model (new business methods, method signature > changes, etc). Definitely! I was trying to understand how best to deal with model drift, and of course, the simplest way would be to generate an interface, and not overwrite any concrete delegates. That way when the interface changes, the compiler would catch the need for new, or modified, business methods. I also thought that an interface wouldn't be necessary since in the <<Entity>> class there will be calls to methods in the delegate, and those method calls would break if the signatures were changed, or methods don't exist. So the compiler would catch the problem there as well, without need for an interface. However, with an interface comes the possibility of implementation replacement. This might allow a concrete implementation to be chosen at runtime, perhaps from some sort of configuration file. But I get ahead of myself. I intend to begin experimenting with this generated architecture today. I'll certainly let you know how it proceeds. If anyone can advise me on methods of 'skipping' the generation of an unneeded class in the model, that would be wonderful. Cheers. -Neal ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
