问抽象:解决问题与解决问题的战争

EN

听哪一遍?多久听一次？

除非你必须，否则不要抽象化。

例如，在Java中，您必须使用接口。它们是抽象的。

在Python中，您没有接口，您可以输入Duck，您不需要很高的抽象级别。所以你就是不知道。

你的策略是什么？

除非你写了三遍，否则不要抽象化。

一次是.一次。解决它然后继续前进。

两次表明这里可能有一个模式。也许就没有了。可能只是巧合。

三次是一个模式的开始。现在它超越了巧合。现在您可以成功地进行抽象了。

你应该把所有东西都抽象出来吗？

不是的。

事实上，你不应该抽象化任何东西，除非你有绝对证据证明你做的是正确的抽象。如果没有“三次重复的规则”，你就会用一种毫无帮助的方式来写一些无用的抽象的东西。

这样做通常会允许我重用代码。

这一假设往往是错误的。抽象一点帮助也没有。这件事做得不好。因此，除非你必须这样做，否则不要这样做。

啊，雅格尼。最被滥用的编程概念。

使代码泛化与做额外工作是有区别的。您是否应该花更多的时间使您的代码松散耦合并易于适应来执行其他事情？绝对一点儿没错。你应该花时间去实现不需要的功能吗？不是的。您是否应该花时间让您的代码与其他尚未实现的代码一起工作？不是的。

正如俗语所说，“做最简单的事情，也可能奏效”。问题是人们总是把简单和简单混为一谈。简单需要工作。但这是值得的。

你能下船吗？当然了。但我的经验是，很少有公司比现在更需要一种“现在就做”的态度。大多数公司需要更多的人来提前思考问题。否则，他们最终总是会有一个自我维持的问题，没有人有时间去做任何事情，每个人都很匆忙，没有人能完成任何事情。

可以这样想:您的代码很有可能会再次被使用。但你不能用这种方式正确预测。因此，让您的代码干净、抽象和松散耦合。但是，不要试图让您的代码使用任何尚未存在的特定功能片段。即使你知道它将来会存在。

三段论：

1. 概括性是昂贵的。
2. 你在花别人的钱。
3. 因此，一般性的费用必须向利益相关者证明是合理的。

扪心自问，你是否真的在解决更普遍的问题，以节省利益相关者的钱以后，或者你只是发现一个智力上的挑战，作出不必要的一般性解决方案。

如果通用性被确定为可取的，那么它应该像任何其他特性一样进行设计和测试。如果您无法编写测试来演示您所实现的通用性如何解决规范所要求的问题，那么就不用费心去做了！一个不符合设计标准且不能被测试的特性是没有人可以依赖的特性。

最后，没有“尽可能普遍”这样的东西。假设您使用C#编写软件，只是为了便于讨论。你要让每个类实现一个接口吗？每个类都是抽象基类，每个方法都是抽象方法？这是相当普遍的，但它远没有“尽可能一般”。这只允许人们通过子类来更改任何方法的实现。如果他们想在不进行子类的情况下更改方法的实现怎么办？您可以使用setter使每个方法实际上都成为委托类型的属性，这样人们就可以将每个方法更改为其他方法。但是如果有人想要添加更多的方法呢？现在每个物体都必须是可扩展的。

此时，您应该放弃C#，而采用JavaScript。但是，您仍然没有达到足够一般的程度；如果有人想要更改这个特定对象的成员查找方式，该怎么办？也许您应该用Python编写所有东西。

增加通用性通常意味着放弃可预见性，大幅增加测试成本，以确保实现的通用性能够真正满足用户的实际需求。这些成本对支付费用的利益相关者是否合理？也许他们是；这取决于你与利益相关者的讨论。我的利益相关者根本不愿意让我放弃静态类型，以追求一个完全不必要和极其昂贵的泛化水平，但也许您的是这样的。