抽象还是不抽象？

Question

前几天，我偶然发现了Linus Torwalds写的一篇相当古老的usenet文章。这是臭名昭著的“你满是胡说八道*”的帖子，当他为自己选择使用普通的C for Git而不是更现代的东西进行辩护时。

特别是，this post让我思考了大量的抽象层，这些抽象层在我工作的地方堆积了一个又一个。我的是Windows .Net环境。我必须说我喜欢C#和.Net环境，它真的让大多数事情变得简单。

现在，我来自一个非常不同的背景，由Unix技术组成，如C和过多的或脚本语言；对我来说，OOP只是一种，但并不总是最好的编程范例。我经常挣扎(当然是以一种工作的方式！)和我的同事(特别是一个)，因为他们似乎是“任何问题都可以通过额外的抽象层次来解决”的教派，而我更倾向于“保持简单”的学派。我认为，对于可能来自于不同文化的问题，有一种非常不同的心理方法。

作为一个非常简单的例子，对于我在这里做的第一个项目，我需要一些应用程序的配置。我创建了一个10行的类来加载和解析一个txt文件，该文件位于程序的根目录中，包含冒号分隔的键/值对，每行一个。啊，真灵。

最后，为了标准化解决配置问题的方法，我们现在在运行每个已配置程序的每台计算机上都有一个库，这些程序调用一个服务，该服务在启动时加载一个xml，该xml包含对包含配置本身的其他xml的引用，每个应用程序一个。

现在，它是可扩展的，并由奇特的可重用抽象、提供程序和所有组件组成，但我仍然认为，如果有一天我们真的重用了它的一部分，并且花费了时间来构建它，我们可以从开始或复制/传递旧代码并修改它。

你对此有什么看法？你能指出一些处理这个问题的有趣的参考资料吗？

谢谢

Answer 1

答案很简单:编程语言提供了数据结构和组合它们的方法。首先直接使用它们，不要抽象化。如果您发现要维护的表示不变量由于大量使用站点可能超出您的控制范围而存在被破坏的高风险，那么可以考虑抽象。

要实现这一点，首先提供函数并转换调用位置以使用它们，而不隐藏表示。仅当您对函数表示足够满意时，才隐藏数据表示。确保在此时记录受保护的不变量。

这是一种“极限编程”版本:在有破坏程序的测试用例之前，不要抽象化。如果您认为不变量可以被破坏，请先编写破坏它的案例。

Answer 2

抽象使得构建软件和理解它是如何组合在一起变得更容易，但它使完全理解围绕性能和安全性的某些问题变得复杂，因为抽象层引入了某些类型的复杂性。

托瓦尔兹的立场并不荒谬，但他是一个极端分子。

Answer 3

这里有一个类似的问题：https://stackoverflow.com/questions/1992279/abstraction-in-todays-languages-excited-or-sad。

我同意@Steve Emmerson的观点--“Coders at Work”会给你一些关于这个问题的很好的观点。