is it bad for design using nested derived classes [closed]

Question

I reading some code written by some other programmer, He made some design for application, application classes derived each other like that:

public interface IABase
{

}
class BBase : IABase
{

}

class CDesktop : BBase
{

}

class Report : CDesktop
{

}

class Sample : Report
{

}

This kind of design is anti pattern? I have to tell first, its realy hard to understand relationship of class and logic of application, this is my 2 cents. What else you can say?

Answer 1

There's a bit of general advice floating around to prefer composition over inheritance. The advantage often touted are that it's more flexible, and 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 for discussions on this matter).

Specifically for C#, it's worth noting that composition can require considerable boilerplate - after all, if you want to expose much of the functionality of the component/base-class, then you'll need to manually expose that; inheritance (by contrast) makes it very easy to just expose everything.

It's probably a good idea to use inheritance sparingly when in doubt because it's easy to create lots of tightly coupled spagetti-monsters otherwise. But there are cases where classical dynamic dispatch and all that is wanted; and there are also cases where even though your concepts better map to a has-a relationship than an is-a relationship the wordiness of composition is a considerable burden.

So while this kind of code is harder to maintain, it might still be worth it on occasion. Your specific example looks like the hierarchy is unnecessarily deep; however, it's normal for old code to grow a few warts - if this is the worst of it, consider yourself lucky.