在实践中如何遵守开闭原则

我了解开放原则的意图。这是通过告诉您尝试在不进行修改的情况下进行扩展，以降低破坏已在修改过程中起作用的内容的风险。

但是，我在理解此原理在实践中的应用时遇到了一些麻烦。据我了解，有两种方法可以应用它。在可能的更改之前和之后：

1. 之前：编程抽象并尽可能“预测未来”。例如，drive(Car car)如果将来将Motorcycles添加到系统中，则必须更改 方法，因此它可能违反了OCP。但是该方法drive(MotorVehicle vehicle)将来不太可能需要更改，因此它遵循OCP。

   但是，很难预测未来并提前知道将对系统进行哪些更改。

2. 之后：需要更改时，扩展类而不是修改其当前代码。

练习1并不难理解。但是，在实践2中，我很难理解如何申请。

例如（我从YouTube视频中获取了它）：假设我们在类中有一个接受CreditCard对象的方法：makePayment(CraditCard card)。将一天Voucher添加到系统中。此方法不支持它们，因此必须对其进行修改。

首先实现该方法时，我们无法预测未来，无法以更抽象的术语进行编程（例如makePayment(Payment pay)，因此现在我们必须更改现有代码。

练习2说，我们应该通过扩展而不是修改来添加功能。这意味着什么？我应该继承现有的类而不是简单地更改现有的代码吗？我是否应该围绕它进行某种包装，以避免重写代码？

还是该原则甚至不涉及“如何正确修改/添加功能”，而是涉及“如何避免必须首先进行更改（即从程序到抽象）”？

设计原则始终必须相互平衡。您无法预测未来，大多数程序员在尝试时都会做得很糟糕。这就是为什么我们有3条规则，这主要是关于重复，但是也适用于任何其他设计原则的重构。

当您只有一个接口的实现时，您无需过多关心OCP，除非可以清楚地知道在哪里进行扩展。实际上，在这种情况下尝试进行过度设计时，您常常会失去清晰度。扩展一次后，如果这是最简单，最清晰的方法，则可以对其进行重构以使其对OCP友好。当您将其扩展到第三个实现时，即使需要更多的精力，也请确保考虑到OCP对其进行重构。

实际上，当您只有两个实现时，添加第三个实现时进行重构通常不太难。当您让它超过该点时，维护变得很麻烦。

我认为您对未来的期望太高了。以灵活的方式解决当前问题，该方式坚持打开/关闭。

假设您需要实现一个drive(Car car)方法。根据您的语言，您有两种选择。

• 对于支持重载（C ++）的语言，只需使用 drive(const Car& car)

  稍后您可能会需要drive(const Motorcycle& motorcycle)，但是不会干扰drive(const Car& car)。没问题！

• 对于不支持重载的语言（目标C），请在方法中包含类型名称-driveCar:(Car *)car。

  稍后，您可能需要-driveMotorcycle:(Motorcycle *)motorcycle，但同样，它也不会干扰。

这允许drive(Car car)封闭修改，但可以扩展到其他类型的车辆。这个极简的未来计划可以让您今天完成工作，但又可以避免将来受到阻碍。

尝试想象您需要的最基本的类型会导致无限回归。当您想要驾驶Segue，自行车或超大型飞机时会发生什么。您如何构造一个单一的通用抽象类型，该类型可以说明人们进入并用于移动性的所有设备？

我了解开放原则的意图。这是通过告诉您尝试在不进行修改的情况下进行扩展，以降低破坏已在修改过程中起作用的内容的风险。

这还与不通过更改现有对象的行为来破坏所有依赖该方法的对象有关。一旦对象通告了行为更改，就很危险，因为您要更改对象的已知和预期行为，而又不确切知道其他对象希望该行为如何。

这意味着什么？我应该继承现有类，而不是简单地更改其现有代码吗？

对。

通过该类的公共界面，“仅接受信用卡”被定义为该类行为的一部分。程序员向全世界宣布，该对象的方法仅使用信用卡。她使用的方法名称不是特别明确，但确实做到了。系统的其余部分都依赖于此。

当时这可能是合情合理的，但是现在，如果需要更改，您应该开设一个新课程，接受除信用卡以外的其他东西。

新行为=新班级

顺便说一句 -预测未来的一个好方法是想想的名字你给的方法。您是否给了一个真正通用的探测方法名称，例如makePayment，该方法在方法中具有特定的规则，具体说明了该方法可以进行哪些付款？那是代码的味道。如果您有特定的规则，则应从方法名称中明确这些规则-makePayment应该为makeCreditCardPayment。第一次编写对象时，请执行此操作，其他程序员将对此表示感谢。