在“ Head First设计模式”一书中，提到的不违反“依赖倒置”原理的方法之一是：
没有一个类来自具体的类。
是否可以完全遵循此规则？在许多常用的框架和库中，常见的是查找不遵循此规则的类。
答案 0 :(得分：2)
继承是c＃的重要组成部分，排除继承是一种浪费。
尽管如此，本书还是强调open for extension closed for change SOLID原理，这实际上是一件好事。
不要从具体的类派生（注意，抽象类和接口不是具体的），可以帮助您适应这种范式。继承通常不适合扩展，并且会使反转变得更加困难（因为后者依赖于接口，而具体对象不是接口）。
因此，在实践中，您会看到基类通常是abstract。不是全部，不是每个框架都采用它。有时，有充分的理由可以从混凝土中继承。但是，这本书从某种意义上来说很容易阅读，并且要详细介绍异常情况将使阅读变得更加困难。
因此，最重要的是：不，一个人不应该不惜一切代价遵循规则，而只有在以下情况之一时才进行具体继承：
答案 1 :(得分：2)
由于编程中的问题非常不同，因此很难说出来。有时您这样做很有用，有时却没有。
还可以重新设计您认为无法实际实现的情况。但是在新设计中，您可能最终得到了更多不必要的类，这些类仅用于实现此目的。
在这种情况下的问题是：是否有更多的东西只是为了实现某种原理而在您的代码中没有问题是一个好的设计？
以我的经验，最好避免使用具体类的继承。尝试设计您的代码，以免您不继承具体的类。这将指导您更好地设计抽象，从而使您的代码更易于阅读和理解。但是有时候这样做是有用的。
正如您提到的，框架就是这样做的。特别是GUI框架。您从那里看到了很多具体类的继承。这是因为向已存在的控件添加其他行为很有用。
例如，Button本身就可以，但是有时您可能需要根据需要添加其他行为。从Button继承并仅添加所需的新东西就可以了。你能用另一种方式吗？当然可以，但是值得避免从具体类继承而从Button添加其他类和/或接口或应对代码吗？是那么糟糕吗？在哪里可以？
您确实以这种方式实现了可扩展性，因为框架仍然可以正常工作。
GUI框架也大量使用合成，因此您得到的是合成与来自具体类和抽象类的继承的结合。只需在需要的地方使用正确的那一个即可。
并非所有问题都类似于具有大量相关对象的层次结构。有时继承会损害可扩展性，而使用组合是更好的选择。