-1

在“Head First Design Patterns”一书中，提到不违反“依赖倒置”原则的方法之一是：

没有类派生自具体类。

是否可以彻底遵守这条规则？在许多常用的框架和库中，通常会发现不遵循此规则的类。

4

2 回答 2

2

继承是c#的重要组成部分，排除它是一种浪费。

尽管如此，这本书强调了open for extension closed for changeSOLID 原则，这实际上是一件好事。

不从具体类派生（注意，抽象类和接口不是具体的），有助于您适应这种范式。继承通常不适合扩展，并且使反转更加困难（因为后者依赖于接口并且具体不是接口）。

所以在实践中，你会看到基类通常是abstract. 不是全部，也不是每个框架都采用它。有时有充分的理由从具体继承。但是这本书很容易阅读，并且详细介绍例外情况会使阅读变得更加困难。

所以底线：不，不应该不惜一切代价遵循规则，而只有在以下情况之一时才进行具体继承：

  • 你知道你在做什么（所以你有一个非常非常好的理由）
  • 你知道没关系（因为它是一个简单的项目/对象）
  • 您知道具体内容将包含在项目本身中（内部）
于 2019-07-20T09:59:57.073 回答
2

由于编程中的问题非常不同，所以很难说。有时您这样做很有用，有时则没有。

也可以重新设计您认为实际上无法实现的情况。但是在新设计中，您最终可能会得到更多您并不真正需要并且仅用于实现此目的的类。

在这种情况下的问题是：拥有更多的东西只是为了实现一些原则而不在代码中出现问题是一个好的设计吗？

根据我的经验，最好尝试避免从具体类继承。尝试设计您的代码，以便您不会从具体类继承。这将使您的代码更好地阅读和理解，因为它可以指导您更好地设计抽象。但有时这样做很有用。

正如您提到的，框架可以做到这一点。特别是 GUI 框架。你会看到很多从那里的具体类继承。这是因为向现有控件添加其他行为很有用。

例如 aButton本身就可以，但有时您可能需要根据需要添加其他行为。继承Button并添加您需要的新东西就可以了。你能用别的方法吗？当然，但是是否值得添加额外的类和/或接口或处理代码Button以避免从具体类继承？有这么糟糕吗？它可以在哪里生存？

您确实可以通过这种方式实现可扩展性，因为该框架仍然可以正常工作。

GUI 框架也大量使用组合，因此您得到的是组合与从具体类和抽象类的继承的组合。只需在需要的地方使用正确的。

并非所有问题都像具有许多相关对象的层次结构那样。有时继承会损害可扩展性，使用组合是更好的选择。

于 2019-07-20T10:54:56.600 回答