Erik,

>I think that this 'trap' can be avoided with smart class design... I can say that I rarely run into this need, because I have tried to provide for it by implementing the correct hooks, and breaking class functionality into enough methods that makes changes easy because of the granularity of responsibility.

I appreciate your very practical comments on avoiding the inheritance trap with hooks and fine granularity of methods. This is helpful.

>If this is, then I think that you are misunderstanding the functionality of the methods in the example I gave. For example: an BizObj.Add method is not a place to add subclass code. Rather, it is a wrapper around a couple of other methods: Validate, BeforeAdd, AddRecord, AfterAdd. Only the AddRecord method has code in it from the parent class, and it knows how to behave because of properties, (which table, PK field, etc), and the rest are hooks, to be called at the appropriate time in the add process.

I'm curious about how you decided on this approach of "before" and "after" hooks. I've seen that done quite a bit in Visual Maxframe, but don't remember reading about it anywhere. Maybe this would be good material for an article.