from our framework docs: "The Top of the Class Heirarchy Should be Abstract
In many cases it is beneficial to provide an abstract base class to extend for your specializations. The majority of the functionality and behavior is well defined. This makes it easier to decipher what the intents of the interface designer were. " While I can understand the reasoning, I cannot agree with the rule. In many cases, abstract base classes lead to separating code that should logically be together into multiple files. When there is one abstract class in the hierarchy, all is well, but when you have two, three or twenty, it is a nightmare. Someone recently dumped some code on my desk where there was a lot of abstract classes being extended. It is a nightmare to figure out what happens, when it happens, and where it happens. So while there is reuse, it comes at too high a cost. One of the nice things about avalon is that it is based more on components instead of inheritance. Unless proven otherwise in a particular case, I favor composition over inheritance. IOW, mr. Foote and mr. Johnson are, in my honest but stubborn opinion, not quite right. Quote could instead be: "The Top of the Class Heirarchy _Could_ be Abstract In _some_ cases it _can_ be beneficial to provide an abstract base class (...) If this is used too much, it leads to The Big Ball Of Mud design pattern." which seems rather stupid to include. thoughts? cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
