对解耦、关注点分离的一点小看法

面向对象对象开发，”抽象“，”封装变化“经常被提及，

还有两个相关联的词也是经常在各种场合出现：“解耦”、“关注点分离”【SOC：Separation Of Concerns】

无论是“抽象”、“封装变化”，还是“解耦”、“关注点分离”，都带来一个很明显的好处：灵活。

首先，我也认同，这几个概念、原则对编程、维护、模块化带来的好处。

但是，我对“灵活”，有另一种理解。

“灵活”在某种程度上，就意味着“复杂”

太灵活的东西，肯定是越复杂，越需要花费更多的时间、精力去理解它。

我个人对这种过于纯粹的东西报以怀疑，实际工作中很多时候这种纯粹的逻辑分离很难实现。

MVC框架：

当一个长期维护的项目，不断增加显示逻辑之后，为了保持View层的这种强制的干净，而在 Action层增加大量处理逻辑，我不觉得维护性会好（也许我理解错了，毕竟没有长期使用过）。

就像前些年Java流行XML配置文件，分离了逻辑，后来又产生了Annotation消灭XML配置文件。

无论分离还是聚合，逻辑是无法消灭的，总是要有一个地方放。

所以到底是多写一些代码来保证View 层看上去很美，还是把显示逻辑全写到View层，

谁又能真正说清楚哪个更好。

总之，还是那句老话，不能为了分离而分离，为了解耦而解耦。

过早优化是万恶之源。

一开始，尽量用简单的方式实现，不要考虑过多细节。除非在前期100%确定是需要被优化，被分离的。

一切伟大的代码，都是在发展中不断演变、不断重构出来的。

评论

1 楼 kiol 2013-08-19  

严重同意最后一句话：一切伟大的代码，都是在发展中不断演变、不断重构出来的。

不过，你对这写原则的理解个人不认同，并不是这些原则不对，而是用的人没有掌握好。建议看看rails，个人感觉rails的设计是很经典的。