1000 层的死亡:Java 中过度抽象的危险

1000 层的死亡:Java 中过度抽象的危险

原文:https://medium.com/hackernoon/death-by-1000-layers-the-perils-of-over-abstraction-in-java-1ad7e58a7127

认识到好的面向对象代码可以更好地伸缩,Sun Microsystems 的训导员规定,Java 中的任何东西都不应该在大厅里游荡或在商场闲逛,而应该被封闭在一个类中。方法取代了函数。字段取代了全局变量。Java 将面向对象提升到了一种盲目崇拜的程度。

不幸的是,Java 的结构诱使粗心的程序员过度抽象。在对所有东西都要求一个类和在编译时强制所有类型之间,它鼓励你在类和接口声明中放下一层又一层的形式主义。

你会被诱惑,或者可能被拖垮,去想象结果是一个有秩序和适应性的美味果仁蜜饼。每一个新的抽象层都是一项资产,一个你将来能够将代码转换的连接点。你模糊地想象,任何一个类变成两个,总有一天会在更好的可重用性或更少的错误方面得到回报。通常将字段隐藏在 getters 和 setters 之后会给你将来改变它们的自由度。

然而,有了这些设计原则,你就有麻烦了。如果你从未遇到过你不喜欢的抽象,随着时间的推移,你的逻辑将会被原子化成微小的类和方法的薄雾,它们中没有一个单独做任何事情。你会发现这一准则难以理解。调试它甚至通读它都会涉及到 pogo——上下粘贴 15 个堆栈帧,一遍又一遍,试图理解其中的逻辑,直到你头晕目眩,忘记了为什么开始。只有项目老手才会真正理解所有的部分是如何组合在一起的。

与此同时,你所设想的适应性将被证明是海市蜃楼。

人们要求的新特性似乎永远不会与你代码中的层次一致。

你不能把这个实现换成那个,你必须一次改变六个不同的模块,并修补一些不幸的外部依赖。尽管您准备在一个眨眼之间重新实现 employee.getEmployeeID(),但是没有人会要求这样做。

你的代码库将会因难以处理和不受重构影响而声名狼藉,因为任何给定的类都会像格列佛一样被一大群小人所牵制。你和你的队友将会害怕接触它,并且梦呓般地谈论你似乎永远没有时间去做的大改写。

你今天是不是患上了千层综合症?还是表现出早期症状?看看你的代码。你看到屏幕上的 2 行和 3 行方法了吗?持有数据但不拥有任何决策权的类,比如 C 结构?只有一个实现的接口?令人困惑的班级名字怎么样?如果您不知道 ParameterInfoBuilderWrapper 应该做什么,或者它与 ParameterInfoBuilder 有什么不同,疾病可能正在向您蔓延。

但是不要害怕。即使你处于晚期,你的病情也是可以治疗的。

首先,忘掉大的重写。重写是一个有风险的策略,花费的时间可能比你想象的要长,同时会让公司的其他人觉得你是人质。如果你当前的版本堆积了太多的层,你的下一个版本也会如此,除非你和你的团队首先掌握了更好的设计方法。所以不要等待大的重写,开始增量地改进你的代码和你的团队。

第二,更新你对健康的看法。

记住,软件的核心是程序性的。

计算机做这个事情,然后他们做那个事情,然后有时做其他事情。高级语言和面向对象的设计声势浩大,分散了我们基本卑微工作的注意力:剔除 if-then 语句。

因此,过程逻辑应该在代码中占据中心位置。好的 Java 应该类似于 c。一个方法应该有一个清晰的、不平凡的工作要做,它应该显示它的工作。您应该能够从头到尾阅读一个方法,并且理解它是如何工作的,而不需要追逐 20 个其他方法的实现。

同样,一个类应该有一些实质性的内容,并承担一些真正的工作。一个经过深思熟虑的类应该拥有一个有趣的决策和做出决策所需的数据,而不仅仅是这个或那个。它应该很容易命名,最好是用一个与现实世界中有自己生命周期的事物相对应的名词。如果你正在努力想出一个名字来区分这个类和那个类,你可能已经考虑太多了。它应该有一个可测试的表面。给这个类一个有限的任务,独立于它的同伴,并编写测试来确保它完成任务。

第三,开始一个锻炼计划。伸出你的食指在你面前,然后在你的 Delete 键上向下弯曲,然后再向上提起。非常好。每次签入的时候做一个报告。将两个两行方法合并为一个。找到一个要删除的小类。丢弃不必要的 getters 和 setters。你不是遮盖脚踝的维多利亚时代的女士;加入那些摇摆的皮托尼斯塔,让你的领域挂出来。

测试每一个接口和受保护的方法:“我们今天需要多种实现吗?”如果你脑海中的声音恳求“但是我们可能想要……”保持冷静,用极限编程的口号赶走它们:“这是不需要的。不会需要的。不会被需要的。”通过使你的代码简短、清晰和经过充分测试来保证你的代码经得起未来的考验,而不是依靠你的洞察力。

最后,动员你的同事加入到这项事业中来,因为你们都在一起。在代码评审中互相挑战。这种方法可以命名得更清楚吗?这个类代表什么很明显吗?这些代码服务于今天的真实用例还是明天的假设用例?明年夏天的实习生会马上明白这个套路吗?

设计是一门艺术。你可以阅读这篇布道中的建议,然后读一本会告诉你恰恰相反的书。重要的是磨练自己的工匠精神。读那些书。实验。辩论。这种投资不仅仅会在生产率的提高和代码的增量改进上得到回报。在你意识到之前,你将把你的一千层减少到可管理的几层,你将享受你改进的速度,你将对你引以为豪的代码库微笑。

原载于 2017 年 10 月 11 日【www.quantcast.com】


本站为非盈利网站,作品由网友提供上传,如无意中有侵犯您的版权,请联系删除