从图片来看，我可以使用继承而不是实现接口吗？
我的意思是从“ConcreteStrategyA 和 ConcreteStrategyB 实现 Strategy 接口”更改为“ConcreteStrategyA 和 ConcreteStrategyB 扩展 Strategy 类”
它仍然运行良好还是有问题？
如果它仍然有效，我的下一个问题是“为什么大多数人更喜欢使用界面？”
【问题讨论】：
标签： oop design-patterns
如您所知，设计模式是“对常见问题的通用解决方案”。它只是描述了一个通用解决方案，没有说明实施细节。
如果您的问题需要一个类来代替接口，那么将其替换为具体（或抽象）类并没有错。
在模式 UML 中使用接口是一种说法：“你必须公开这组公共方法”。
所以，使用您的方法没有问题。作为替代方案，您可以保留Strategy 接口并在StrategyImpl 类中实现它，然后您可以在ConcreteStrategyA 和ConcreteStrategyB 类中继承该类。
【讨论】：
当然。当您希望派生策略共享一些公共代码时，继承最常与抽象基类一起使用。
人们更喜欢使用接口或抽象类而不是具体的基类，因为：
使用依赖倒置方法，类需要与其策略松散耦合。它只需要知道 Strategy 履行合约，而不想知道它的实现细节。接口和抽象类是在不指定实现的情况下定义契约的一种优雅且极简的方式。
大多数时候实例化基础 Strategy 类没有意义，因为它是一个通用的抽象概念——事实上，最好禁止实例化它。
【讨论】：
从策略模式的设计模式的角度来看，从技术上讲，具体的策略需要实现（我的意思是编写代码，而不是接口实现事物）策略上下文知道的公共合约。这是战略模式哲学的主要支柱。遵守公共契约是允许策略上下文基于某些运行时特性替换具体策略的原因。这种模式思想就是我们在 OOP 用语中松散地称为多态性。 现在在 Java 中，您可以将他的多态策略实现为接口或继承。对于界面，您已经在问题本身中给出了示例。对于继承，只要子类之间存在契约（类似于具有抽象契约的基本抽象类，子类实现以提供具体的策略实现），您也可以在继承中实现策略模式。
现在从 OOP 的角度考虑它。对于 OOP，继承是子类从超类继承的东西。子类自动拥有并因此演示了继承的泛型行为，但它可以选择使该行为更特定于它自己的类型。因此，多个子类可以覆盖相同的行为，并使其中的某些部分更具体地用于它们的用途。但是当这条链变得太长或者当子类试图继承在逻辑上不适用于它们的行为时，这条链变得难以管理。
因此，使用接口实现策略模式而不是继承更有意义。
【讨论】：
没有技术问题。
然而，一个类只能扩展一个基类，但它可以实现多个接口。因此，如果您想在将来更改继承结构，则选择实现接口会更容易。
【讨论】：