关于程序,曾经有两个著名的公式:
程序=数据结构+算法;
程序=(数据结构+算法);
前者的代表是面向过程的编程方式,后者的代表,我想应该是OO了吧。OO的基本特点——封装,将数据与对于数据的操作放置一起:隐藏数据、公开操作,达到以更贴近真实世界模型的方式,实现以基于操作对象(其实只是调用对象的公有接口)的方式开发复杂的应用。看到软件开发过程的变迁:面向过程的开发方式下,瀑布模型是十分合理的;但如果没有OO,在面向过程的开发方式下,要实现对较复杂应用所适用的迭代模型,可能会导致花费巨大,最终可能也仍然发现,这是几乎不可能的任务。
这样看来,数据与对数据的行为的合并,自然是OO的天经地义了。可问题是,在OO的开发中,特别是针对分布式及分层开发,我们常常会习惯性的把层次分为数据实体层、数据访问层、业务逻辑层、外观层等等。也许,他们有更专业的叫法:实体类(模型)和控制类(控制器)。(不知道为什么会这么做,似乎我刚开始接触分层开发的时候,就开始这么做了。)
探究实体类和控制类的起源,不是件容易的事吧。或许,是在将面向过程的程序向OO迁移的时候所做的折中吧。不过,实体类和控制类的分离,是不是人为的导致了数据和行为和分离,而造成了对OO基本原则的违反呢?更危言耸听一点,是不是可以说,是倒退到了面向过程的老路上?
当面对下一个问题的时候,是秉持OO的原则,数据和行为绑定,还是按照习惯,实体类和控制类分离来分层呢?
OO的困惑
最新推荐文章于 2024-09-10 21:54:53 发布