如何摆脱工具类

正文

请到「今天看啥」查看全文

如需转载，发送「转载」二字查看说明

无论是进行代码review还是紧急编码调整，你总会发现：你又搞出了一个帮助类（helper class）。代码运行一切正常，进度又必须跟上，发布任务一个接一个，因此那个帮助类逐渐变成了一个提供了很多静态（static）方法的“怪兽类”（monster class），在它的utils包内不受控制地增长。utils包长久以来就是一个技术争议的荒蛮之地，面向对象设计理念连半步都不敢踏入。“工具类是功能集中，并且逻辑毫不重复（Do not repeat yourself）” 一些开发人员会这样喊道 ，通常就是他们编写了这些工具类。因为所有都是静态的，所以它很快 － 团队里面的另外一些人这样说，也许就是是添加另外一些静态方法的人。它很容易使用，我们使这些代码很简洁 — 你可以在这个空间内听到这样的言论，但这又是另外一个对KISS的误解了。

我们会争论到：通常帮助类和工具类都很简单，特别是当我们不能修改新功能的目标类（例如外部依赖库）或我们不能找到使用的目标（不清晰的领域模型，PoC，需求缺失），或者我们只是不想去找它（懒，这也是帮助类的最主要原因）。但是最大的问题在于这很明显不是面向对象的解决方案，并且随着时间的推移（缺少团队沟通，资源重用，快速修复和一些其他的东西）它会导致一些包含无尽静态方法的容器和令人头疼的维护（你想要做到DRY，但你却是用10个方法来提供几乎相同的功能，尽管不是完全一样；你想要快速，但你现在不能方便地添加一个cache机制到那个静态类中或者你遇到了并发的麻烦；你想使事情变得简单，但现在你的IDE提供了一长列的各种各样的方法，这并不能简化你的工作）。但不要担心，我们会尝试着去解决它。

请到「今天看啥」查看全文