企业级应用，有什么理由不用OO？

         这里所谓的企业级应用，就是Martin Fowler的企业应用架构模式中论述的企业级应用。

         在软件工程过去的40年里，虽然没有任何一种方法论能够达到舍我其谁的程度，但是确实在工业界和学术界达成了一些共识：封装，行为优先于数据考虑，依赖于抽象而非具体，迭代开发，领域驱动设计……而OO范型是这些最佳实践的最好集合。

         软件的设计，来自对于问题域的抽象，随着对于需求的理解深入，我们的设计会随之演化。结构化范型中首先设计数据库，我认为过早的对问题域进行了数学抽象，往往那些抽象过于远离问题域，它代表了当时对于问题域的理解。而数据库又属于依赖的最低层，这种不牢靠的抽象必然会造成设计的不稳定，因此从本质上讲，这种方法就是不可靠的。而OO可以直接去模拟业务领域，可以尽可能的去贴近实际。因为实际业务运行良好，那么你所设计的模型也会更容易的运行良好。我发现越是贴近现实领域的建模，其进化性越好。

       问题领域中不仅包含实体，还包含值对象，服务[Evans03]，而数据库建模则往往只强调实体。那么其他有用领域概念就在设计中丢失了。制作大而全的对象是不切实际的，对象属性和行为的确定要来自于业务需求，对象使得添加和减少属性和行为都变得容易。

       把一些行为和数据按照主题加以分类，写到不同文件里，就像我们写文章需要划分段落一样，每个段落表达一个意思，如果想补充表达某个意思，就去相应的段落扩展。而类就是这一个个段落。当某个段落表达了不同的意思，就按不同的意思分解。我想这和单一职责原则是有同构性的。那一个个函数就像一个个句子，面向过程设计将这些句子按照应用分布在应用中，而面向对象设计奖这些句子按主题分布在具有业务语义的类中。

     企业级应用的特点是：复杂和多变。一个复杂的东西在变是最让人痛苦的。于是尽可能要把它分解为小而简单的东西，让每个变化只局限于一个方面。

     某些东西是不容易变化的，比如商业，申请服务，提供/享受服务，结帐，这个大方向是不会变的。商业的一个子集，餐馆，上千年了，基本流程还不是点菜，上菜，买单？菜和帐是千年不变的实体。

     无疑，OO比数据库建模向前又走了一步。

      做了几个大型系统，和一些需求模糊、变化无常的项目，真找不出什么理由，做企业级应用可以不用OO。

     2008年4月10号补充：但是，现实情况却是，很少有项目采用OO范型，人们认为无论什么方法都不可能彻底解决企业应用核心复杂性（即问题域复杂），转而走向干脆不尝试OO。特别是在这个行业混迹多年、并且在学校只学了结构化方法的人。我与几个公司的信息部的人聊天，他们采用的方法都是先设计数据库，然而我用OO为系统添加了一项功能（我们为他们公司开发了系统，然后我去添加新功能），他们对于使用OO表示赞同，觉得是好方法。但是却没有使用。

  

      2008年4月13号补充：需求调研一个阶段告一段落，回到北京准备考试。在火车上一直跟同学讲领域驱动开发，讲我过去做的两个使用OO开发的项目的感受，并对比之前使用面向过程方法做项目的感觉：

      1 领域驱动设计，越是复杂、变化灵活的项目越要采用贴近领域的对象模型，只有小的项目才可以尽可能简化对象使得测试刚好通过即可。

      2 切忌UI驱动设计。我做的视频监控项目从最初的需求里包含GUI，到后来不要UI，真是惊天动地的大变化。另外一个作业管理的界面我们修改了20多版，而业务还是那点儿业务。UI可以辅助挖掘需求，但是把它作为最后一件事完全可以。

      3 切忌数据库驱动设计。关系数据库以数学为基础，距离现实领域太远，过早陷入其中危害无穷。

      4 面向对象是比面向数据、面向过程更加先进的方法。我说，当做那个作业管理子系统时，我将函数拆分的非常细，每个函数都是单一职责的，但是管理起来很费劲。我举例说，比如你有一堆帮助文档，包含了J2EE的方方面面，为了方便查找，我想你可能会按照主题将他们放在不同的文件里，然后再放到不同的文件夹里。那么这些文件就是类，文件夹就是包。虽然面向过程编程，你可以采用良好的命名规范，并将其放入单独的文件里（比如Delphi的unit，VB的module），但是其封装性和复用性明显要弱于OO。也就是这种最佳实践再向前迈一步就是OO了。

      5 我的感觉是，越是大型、复杂的商业应用越适合采用OO。虽然OO不完美，OO不是银弹，OO也没有REST、SSOA等时髦，也许话题很陈旧，很“入门”，但是，OO在国内应用的现状，就足以反映出，这是个值得探讨的问题。

 

 

[Evans03]Eric Evans，2003，领域驱动设计：软件核心复杂性解决之道。

OO出来前也有企业级应用..甚至现在80%的企业应用(出自CICS的说明书)还都不是OO, COBOL照样可以支撑一个企业的系统.

OO照样处理不了需求变化的情况,对于需求来说,OO太细小了.

我只是说对于企业应用而言，与众多方法比较，OO是最好的，那么为什么我们不用OO呢~~

关于应对需求，我只是觉得，OO能更好的随需求变化提供进化式设计的可能。

OO可以成就项目，也可以破坏项目，非OO也可以成就项目，同样也可破坏项目，既然如此，OO不是重要的结果才是重要的，OO就像C++，不完美，也不简单。为什么你任务OO对企业应用而言就是最重要的吗，最重要的是什么，是金钱和时间，OO也许不总是对的

你这个太细小做何解释 不太明白

要看项目的类型。

往往一个项目起来的时候，用户最大的需求是保留当前已有系统的使用习惯，或者要与已有的很多系统进行无缝整合。此时，已经存在了一些很多年前设计的数据库表，以及大量的数据，你要OO，可以啊，先把这些数据迁移过来再谈编程哲学，这时，往往会觉得力不从心。

还有一类项目，完全就是从无到有的，那么尽可能的放开手脚，想怎么玩就怎么玩吧。

就算是OO无处不在，和企业级应用扯到一起，
就好比举起榔头，到处都是钉子一样。

[quote="downpour"]要看项目的类型。 往往一个项目起来的时候，用户最大的需求是保留当前已有系统的使用习惯，或者要与已有的很多系统进行无缝整合。此时，已经存在了一些很多年前设计的数据库表，以及大量的数据，你要OO，可以啊，先把这些数据迁移过来再谈编程哲学，这时，往往会觉得力不从心。 还有一类项目，完全就是从无到有的，那么尽可能的放开手脚，想怎么玩就怎么玩吧。[/quote] 其实这些并不矛盾 数据库只是作为持久化的工具而已 跟OO设计并不矛盾，将对象映射为一个并不OO的数据库表也是可以的 我大四做的项目就是为一个遗留系统（一个大型公司的生产业务系统）添加视频监控功能，采用的OO设计，迭代了17版，没什么问题。

我说的是：目前来说，企业级应用最好的方法是OO
我没说OO无处不在，数学运算等领域，OO并不适用或最好

我觉得不必过于叫真，OO的确是一个十分好的设计方式，企业级应用中似乎国外的很多开发公司都注意到了过去不断叫嚣OO是无意义的，因为企业中最大量的还是数据，处理这样大量的数据很大程度上使用一个稳定的、成熟的数据结构式的编程还是十分理想的开发方式。