Many interfaces and lots of inheritance vs few interfaces and less inheritance? I have a Visual Studio Solution which has a bunch of Projects in it. One of these projects is called "Services" and is basically the junction point between all remaining projects. When I built it originally I made it as generic as possible so I can expand on it. At the time I only had to work with Entity Framework backed implementations of it, but now I've added QuickBooks to the mix as well. It mostly worked out well, but I saw the need to refactor and redesign bits and pieces of it. To that end I've spent most of yesterday doing that and I have new code that takes care of the weirdness I had before, but, I find myself using lots of interfaces and lots of inheritance and I'm not exactly comfortable with it. For example here's my "DbService" implementations:

public class DbService&lt;TEntity&gt; :
    Service&lt;TRepository&gt;,
    IDbQueryableService&lt;TEntity&gt;,
    IQueryableService&lt;TEntity&gt; {}

public class DbService&lt;TEntity, TKey&gt; :
    DbService&lt;TEntity&gt;,
    IDbGettableService&lt;TEntity&gt;,
    IGettableService&lt;TEntity, TKey&gt;,
    IRemovableService&lt;TEntity, TKey&gt;,
    IRestorableService&lt;TEntity, TKey&gt; {}

public class DbService&lt;TEntity, TEntityFormItem, TKey&gt; :
    DbService&lt;TEntity, TKey&gt;,
    IAddableService&lt;TEntityFormItem, TKey&gt;,
    IUpdatableService&lt;TEntityFormItem, TKey&gt; {}

public class DbService&lt;TEntity, TEntityFormItem, TEntityListItem, TKey&gt; :
    DbService&lt;TEntity, TEntityFormItem, TKey&gt;,
    IDbListableService&lt;TEntityListItem&gt;,
    IListableService&lt;TEntityListItem&gt; {}

public class DbService&lt;TEntity, TEntityFormItem, TEntityListItem, TEntitySelectItem, TKey&gt; :
    DbService&lt;TEntity, TEntityFormItem, TEntityListItem, TKey&gt;,
    IDbSelectableService&lt;TEntitySelectItem&gt;,
    ISelectableService&lt;TEntitySelectItem&gt; {}


This is very similar to my current code and allows me to only inherit from a base class that has the functionality I want. For example, if a TEntity can be listed, but doesn't need to be displayed as a select list, then I'll inherit from the fourth DbService. This way I know I can upgrade or downgrade my inheritance as I need to. That being said, it itself has a lot of inheritance between base classes and interfaces. There's six levels of base class inheritance and 12 interfaces.

So, this morning I tried to bring it all together a little bit and came up with this:

public class DbService2&lt;TEntity, TEntityListItem, TEntitySelectItem, TKey&gt; :
    Service&lt;TRepository&gt;,
    IDbReadableService&lt;TEntity, TEntityListItem, TEntitySelectItem&gt;,
    IReadableService&lt;TEntity, TEntityListItem, TEntitySelectItem, TKey&gt; {}

public class DbService2&lt;TEntity, TEntityFormItem, TEntityListItem, TEntitySelectItem, TKey&gt; :
    DbService2&lt;TEntity, TEntityListItem, TEntitySelectItem, TKey&gt;,
    IWritableService&lt;TEntity, TEntityFormItem, TKey&gt; {}


Now this version obviously reduces the depth of inheritance on the base classes to three and the interfaces to three, but, it forces me in a position where some inheriting TEntity services will not be using all of the features so I'd have to use placeholders to fill in some of the TEntity* parameters and that feels like it will end up dirtier in the long run than the first code sample.

Also, I do realize that I'm using lots of generic parameters, but it works for my needs and this not being a publicly exposed API, I'm OK with it.

So, my question for you fine folks is, am I being too zealous in trying to reduce the base class and interface inheritances or am I OK to continue as is, which has worked so far (referring to the original code I was refactoring which is very close to the first example)? Visual Studio gives the first example a maintainability index of 86.5% (average), and 82.5% (average) for the second example, so if I follow VS assessment, I should continue with the first example?
Zealous nitpicking...

am I being too zealous in trying to reduce the base class and interface inheritances

Careful with wording here: a type inherits from a base class, and implements an interface. Interfaces aren't inherited, they're implemented. Subtle, but important distinction.

My two cents...
Looking at the base class in the first snippet:

public class DbService&lt;TEntity&gt; :
    Service&lt;TRepository&gt;,
    IDbQueryableService&lt;TEntity&gt;,
    IQueryableService&lt;TEntity&gt; {}


Can you spot the code smell?
What's the difference between these two interfaces?

    IDbQueryableService&lt;TEntity&gt;
    IQueryableService&lt;TEntity&gt;


You're not listing any of these interfaces, but just from the names one can tell that IQueryableService&lt;TEntity&gt; and IDbQueryableService&lt;TEntity&gt; probably overlap in functionality: they're both queryable services.
Leaky abstractions
What you have here is a leaky abstraction: you're making an abstraction (/interface), but the implementation is leaking into the abstraction - whether the data is coming from a database, from a web service, or from text files, shouldn't matter; you want an abstraction for something that can be queried... and IQueryableService&lt;TEntity&gt; seems to accomplish that. IDbQueryableService&lt;TEntity&gt; is leaking a database implementation of an IQueryableService&lt;TEntity&gt;.
IDbQueryableService&lt;TEntity&gt; is redundant and should be removed.
Same goes for IDbGettableService&lt;TEntity&gt;, which is leaking a database implementation of IGettableService&lt;TEntity, TKey&gt;, at least so it seems from the interfaces' names.
Consistency in design
Where's IDbRemovableService&lt;TEntity&gt;? Where's IDbAddableService&lt;TEntity&gt;? Where's IDbUpdatableService&lt;TEntity&gt;? Why aren't these operations paired with a non-IDbSomething interface like the queryable and gettable stuff?

I would have lots of other questions about why you need to have a TEntityListItem (among other things), but there's really not enough context in your question to pursue any further without assuming what your implementations do, and what methods your interfaces expose.
I suggest you post another question with your actual code, so reviewers can actually go over your code and make sound recommendations. Just reviewing class names and interfaces without even having the interface members, is pretty hard.
I would venture to say that I highly doubt you need that many generic type parameters, but without knowing more about your code all I can do is say &quot;I don't like this&quot;; whether it's a private API or publicly exposed to client code doesn't matter: it's code that you need to maintain and understand, now and in the future - I don't care what Visual Studio thinks the &quot;maintainability index&quot; is (especially when anything between 20 and 100 is &quot;green&quot;). Having 12 different interfaces that, together, seem to be doing what a single repository could do, doesn't feel right. In fact, the first impression I got was &quot;boy this is over-engineered&quot;. And I'm sure the impression wouldn't go away by looking at your actual code.