对解耦、关注点分离的一点小看法
面向对象对象开发，”抽象“，”封装变化“经常被提及，
还有两个相关联的词也是经常在各种场合出现：“解耦”、“关注点分离”【SOC：Separation Of Concerns】
无论是“抽象”、“封装变化”，还是“解耦”、“关注点分离”，都带来一个很明显的好处：灵活。
首先，我也认同，这几个概念、原则对编程、维护、模块化带来的好处。
但是，我对“灵活”，有另一种理解。
“灵活”在某种程度上，就意味着“复杂”
太灵活的东西，肯定是越复杂，越需要花费更多的时间、精力去理解它。
我个人对这种过于纯粹的东西报以怀疑，实际工作中很多时候这种纯粹的逻辑分离很难实现。
MVC框架：
当一个长期维护的项目，不断增加显示逻辑之后，为了保持View层的这种强制的干净，而在 Action层增加大量处理逻辑，我不觉得维护性会好（也许我理解错了，毕竟没有长期使用过）。
就像前些年Java流行XML配置文件，分离了逻辑，后来又产生了Annotation消灭XML配置文件。
无论分离还是聚合，逻辑是无法消灭的，总是要有一个地方放。
所以到底是多写一些代码来保证View 层看上去很美，还是把显示逻辑全写到View层，
谁又能真正说清楚哪个更好。
总之，还是那句老话，不能为了分离而分离，为了解耦而解耦。
过早优化是万恶之源。
一开始，尽量用简单的方式实现，不要考虑过多细节。除非在前期100%确定是需要被优化，被分离的。
一切伟大的代码，都是在发展中不断演变、不断重构出来的。
