OO的困惑

关于程序，曾经有两个著名的公式：

      程序＝数据结构+算法；

      程序＝（数据结构+算法）；

  前者的代表是面向过程的编程方式，后者的代表，我想应该是OO了吧。OO的基本特点——封装，将数据与对于数据的操作放置一起：隐藏数据、公开操作，达到以更贴近真实世界模型的方式，实现以基于操作对象（其实只是调用对象的公有接口）的方式开发复杂的应用。看到软件开发过程的变迁：面向过程的开发方式下，瀑布模型是十分合理的；但如果没有OO，在面向过程的开发方式下，要实现对较复杂应用所适用的迭代模型，可能会导致花费巨大，最终可能也仍然发现，这是几乎不可能的任务。

  这样看来，数据与对数据的行为的合并，自然是OO的天经地义了。可问题是，在OO的开发中，特别是针对分布式及分层开发，我们常常会习惯性的把层次分为数据实体层、数据访问层、业务逻辑层、外观层等等。也许，他们有更专业的叫法：实体类（模型）和控制类（控制器）。（不知道为什么会这么做，似乎我刚开始接触分层开发的时候，就开始这么做了。）

  探究实体类和控制类的起源，不是件容易的事吧。或许，是在将面向过程的程序向OO迁移的时候所做的折中吧。不过，实体类和控制类的分离，是不是人为的导致了数据和行为和分离，而造成了对OO基本原则的违反呢？更危言耸听一点，是不是可以说，是倒退到了面向过程的老路上？

  当面对下一个问题的时候，是秉持OO的原则，数据和行为绑定，还是按照习惯，实体类和控制类分离来分层呢？