Arn*_*psa 12
"简单而复杂,复杂而不复杂"
所以 - 只有当你"复杂化"复杂性的复杂性时,抽象某些东西才有好处.这样做的原因可能有所不同:更好的模块化,更好的封装等.
识别过度抽象是鸡和蛋的问题.为了减少过度抽象,您需要了解代码行背后的实际原因.这包括理解特定抽象本身的想法(与将其称为缺乏理解的抽象原因相反).这还不够 - 你需要知道一个更好,更简单的解决方案来证明它已经过度抽象了.
如果您正在寻找可以在您的位置执行此操作的工具 - 请不要再看,只有大脑才能可靠地判断出来.
Ytt*_*ill 12
我会给出一个会得到很多票数的答案!
如果代码是用OO语言编写的话,则必然会过度抽象.语言越纯,问题越严重.
应该非常谨慎地使用抽象.如果有疑问,总是使用具体的数据结构.(你可以随后抽象,这比去抽象更容易:)
你必须非常肯定你在当前的背景下有正确的抽象,你必须非常肯定这个概念将经得起变革的考验.抽象在代码和编码器的性能上都有很高的代价.
过度抽象的一些弱测试:如果数据结构是产品类型(C中的结构)并且程序员已经为每个字段编写了get和set方法,那么它们完全无法提供任何真正的抽象,像C增量这样的禁用运算符,没有任何意义,并且根本不理解struct字段名称已经是产品的抽象表示.复制和编写界面并不是一个好主意.
对产品案例的一个很好的测试是,是否存在任何要维护的数据不变量.例如,表示有理数的一对整数几乎就足够了,几乎不需要任何抽象,因为除了分母为零之外,所有对都是有效的.然而,出于性能原因,可以选择保持不变量,通常分母要求大于零,并且分子和分母是相对素数.为了确保不变量,产品表示被封装:由构造函数保护的初始值和约束维护不变量的方法.
要修复代码我建议这些步骤:
记录抽象维护的表示不变量
如果找不到强不变量,请删除抽象(方法)
使用该方法重写代码以直接访问数据.
此过程仅适用于低级抽象,即按类抽象小值.
过度抽象处理更难以处理.理想情况下,您将重复重构代码,检查每个步骤后是否继续工作.然而,这将很难,有时需要重大改写,而不是改进.这可能是不值得的,除非抽象是远离基础,它不能继续维持它.
| 归档时间： |
|
| 查看次数： |
4360 次 |
| 最近记录： |