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
Post a Comment