如何识别代码过度抽象?

“简单胜过复杂,复杂胜过复杂”

所以-只有当你将复杂度“去水平化”为复杂度时,抽象的东西才有好处。这样做的原因可能不同:更好的模块化,更好的封装等。

如果你正在寻找一种工具,可以在你的位置上做它-不要再看了,只有头脑可以可靠地判断。

我会给一个答案,会得到很多反对票!

使用抽象应该非常谨慎。如果有疑问,请始终使用具体的数据结构。(您可以稍后进行抽象,这比反抽象更容易:)

你必须非常确定你在当前的上下文中有正确的抽象,并且你必须非常确定这个概念将经得起变化的考验。抽象在代码和编码器的性能上都有很高的代价。

对于过度抽象的一些弱测试:如果数据结构是一个产品类型(C中的struct),程序员为每个字段编写了get和set方法,他们完全不能提供任何真正的抽象,禁用了C increment之类的操作符,毫无目的,而且根本不明白struct字段名已经是产品的抽象表示了。复制和放大接口不是一个好主意。

对产品案例的一个很好的测试是是否存在需要维护的数据不变量。例如,一对表示有理数的整数几乎就足够了,几乎不需要任何抽象,因为除了分母为零时,所有对都是有效的。然而,出于性能原因,人们可以选择保持不变,通常分母必须大于零,分子和分母是相对素数。为确保不变量,产品表示被封装:初始值由构造函数保护,方法被约束以保持不变量。

要修复代码,我建议执行以下步骤:

1. 记录抽象所维护的表示不变量

2. 如果找不到强不变量,请删除抽象(方法)

3. 使用直接访问数据的方法重写代码。

此过程仅适用于低级抽象,即按类抽象小值。

在更高的层次上过度抽象是很难处理的。理想情况下,您应该反复重构代码,检查每一步之后代码是否继续工作。然而,这将是困难的,有时一个重大的重写是必要的,而不是完善。这可能不值得,除非抽象离基础太远,无法继续维护它。

下载Magento并查看代码,阅读其中的一些文档并查看他们的ERD: http://www.magentocommerce.com/wiki/_media/doc/magento---sample_database_diagram.png?cache=cache

我个人会说,“什么是理想的抽象层次?”是一个主观问题。

我不喜欢每一个原子操作都使用新行的代码,但我也不喜欢一行中包含10个嵌套操作。

我喜欢泛型,但我不喜欢(嵌套的)泛型函数,例如,为每个预期的特定类型使用不同的代码。。。

这是个人意见和常识的问题。这能回答你的问题吗?

我完全同意什么 @ArnisLapsa

"Simplicity over complexity, complexity over complicatedness"

然后呢

an abstraction is used to "de-level" those, from complicated to complex

另外,正如 @MartinHemmings

• 与之相关的人
• 它的实现应该只考虑抽象,而不是它将用于的具体案例。一旦抽象实现有针对特定情况的部分,它就表示“不合适”的抽象。为了应对每一个新的情况而增加泛化,这是走错了路(而且往往会落在下一个问题上)。
• 我发现一个非常常见的过度抽象的指标(实际上是我所喜欢的)是抽象,它代表了比需要更多的东西, . 他们应该尽可能地允许自己做所需的事情,但不允许做更多的事情。例如,假设您正在考虑或已经有一个“2d点”抽象,您可以为它定义许多您需要的操作符。然后你有另一个需要,可能是一个“4d点”类似于2d,不要开始使用“nDimensional点”抽象,特别是你以后可能会需要它。也许除了2和4d你永远不会有别的东西(因为它永远是积压工作中的“一个好主意”),但是相反,有些需求会突然出现,将4d点转换成成对的2d点。这很难推广到n维。因此,可以检查每个抽象以涵盖
• 最后,从更全局的角度来看,具有许多不相关抽象的代码库是开发团队倾向于抽象每个小问题的一个指标。所以他们中的许多人可能已经或者变得过于抽象了。