c# - is it bad for design using nested derived classes -


i reading code written other programmer, made design application, application classes derived each other that:

public interface iabase {  } class bbase : iabase {  }  class cdesktop : bbase {  }  class report : cdesktop {  }  class sample : report {  } 

this kind of design anti pattern? have tell first, realy hard understand relationship of class , logic of application, 2 cents. else can say?

there's bit of general advice floating around prefer composition on inheritance. advantage touted it's more flexible, , discourages tight coupling more. (see where-does-this-concept-of-favor-composition-over-inheritance-come-from, deepclasshierarchies, deep-class-inheritance-hierarchy-bad-idea, long-inheritance-hierarchy amongst many others discussions on matter).

specifically c#, it's worth noting composition can require considerable boilerplate - after all, if want expose of functionality of component/base-class, you'll need manually expose that; inheritance (by contrast) makes easy expose everything.

it's idea use inheritance sparingly when in doubt because it's easy create lots of tightly coupled spagetti-monsters otherwise. there cases classical dynamic dispatch , wanted; , there cases though concepts better map has-a relationship is-a relationship wordiness of composition considerable burden.

so while kind of code harder maintain, might still worth on occasion. specific example looks hierarchy unnecessarily deep; however, it's normal old code grow few warts - if worst of it, consider lucky.


Comments

Popular posts from this blog

database - VFP Grid + SQL server 2008 - grid not showing correctly -

jquery - Set jPicker field to empty value -

.htaccess - htaccess convert request to clean url and add slash at the end of the url -