SkyIsland 在坛子上提问到底什么是面向对象，其中一段话列举了他的工作思维过程，他认为这应该已经是面向对象的开发思维了
---------------
到底什么是面向对象？
用户输入数据—>Test.aspx(Test.cs)—>TextBox.Text接收—>用DataInfo.cs保存—>在BLL.Data中处理逻辑—>用DAL.Data(调用DBHelper.cs)执行SqlCommand，这怎么就变成面向过程了？
---------------
就SkyIsland的疑问，我说说自己的看法做为一个编程菜鸟，我学习编程时首先考虑的是寻找最傻瓜化最自动化的工具来实现业务需求，如果有一台机器能够由我说一句“造房子”，再输入几个参数，它就能造出幢符合要求的房子来，那么只要综合成本被评估为“合理”，我就一定会买（或租用）这台机器，成本合理的情况下我是不会考虑自己动手或请施工队来盖房子的，然后我找到了ECO框架（版本是ECOIII），.NET环境下的一个ORM框架在ECOIII的框架下，我的工作思维模式是怎么样的呢？我描述出来跟SkyIsland的工作思维模式对比一下SkyIsland的开发过程：
用户输入数据—>Test.aspx(Test.cs)—>TextBox.Text接收—>用DataInfo.cs保存—>在BLL.Data中处理逻辑—>用DAL.Data(调用DBHelper.cs)执行SqlCommand我在ECOIII框架下的开发过程：
分析一个需求项目所涉及的对象->根据对象实例的共性提取实体类，确定实体类的属性与行为->根据实体类的共性提取抽象类，确定类的相互关系，描绘ER图与状态图->编译，ECOIII框架根据ER图与状态图自动生成基础代码->用对象查询语言（OCL）确定对象信息集控件（EH）获取的对象信息（可以是对象的基础信息或派生信息）->将界面控件与对象信息集控件相关联以获得系统的界面表达->编译运行程序，在界面中输入业务数据测试业务逻辑是否正确->业务逻辑测试完毕，将程序块打包->如果暂时没有数据持久化保存的要求的话，工作结束看到这里，可以发现我的工作过程中大部分的工作是在确定业务对象与业务逻辑----是不是更贴合“面向对象开发模式”这个词呢？？我的开发过程是不涉及数据库的，程序完成后，是可以运行在无数据库的环境下，既不涉及数据库文件，也不涉及数据库查询语言（比如SQL语言），只有当我们有保存数据的要求时（也就是有数据持久化的要求时）才会考虑到数据库那么当有人提出数据持久化的要求时，我会再做些什么呢？非常简单的事情，ECOIII提供了一个完全自动化的ORM环境，我所要做的就是给这个程序包加一个数据库映射控件而已，然后ECOIII根据所选择的数据库产品类型自动生成相应的数据库结构，现在再次运行程序，我所输入的业务数据就可以持久化保存了，数据库对我而言，不过是可以随时选择的存储介质而已，跟业务逻辑毫无关系，我的工作过程不再考虑表、表结构、表查询等等是什么东西，我考虑的基本上是“我要管理什么对象”、“我要取得什么对象的什么信息”这类事情，数据存储过程在我的工作过程中是由ECO框架自动执行的，我不需要考虑了事实上我本人到目前为止还没有学习过数据库知识，因为在ECOIII的环境下，我用不到数据库知识当然了，你也完全可以考虑自己搞个ORM框架，同样的，如果你搞出一个ORM框架，那么你的工作方式就应该是面象对象的分析、面向对象的设计，完成业务逻辑，然后将已完成的业务逻辑通过你的ORM框架挂接上具体的数据库也就是说，在面向对象的开发模式下，除了ORM（对象/关系数据库映射）工作以外的开发过程应该是与数据库零相关的，如果你所采用的开发环境包含有全自动的ORM能力，则你的开发全过程都应该是与数据库零相关的除了开发过程与数据库零相关，更重要的是，你工作的大部分内容应该是确定“我要管理什么对象”、“我要管理的各个对象之间的关系是怎么样的”，“我要取得什么对象的什么信息”如果没有类似ECO这样的自动代码工具，可能完全面向对象的开发过程会让程序员很不舒服，因为有人说按一个个类进行开发，代码量很大（真的吗？我没有经验不好下结论，有过对比经验的人来说一说），但在有自动代码工具的情况下，效率应该是极高的，事实上在ECOIII框架下开发，手工代码量是少的可怜的完全面向对象开发的另一大特点是，由于程序包跟数据库完全无关，任务分包可以分的非常清晰，一个大项目由N个小积木堆成的想法是可以实现的，同时一个项目需求分析出来的类不仅可以在同一个项目中的其它包里复用，而且可以在多个项目中复用，整个包也可以复用，假使需求有所变动，你最主要的修改工作将是去修改图纸，而不是去修改代码从公司的实践来看（我本身不是开发人员而是业务人员，但公司有正规的程序开发人员），面向对象的开发模式不管是针对复杂度很低的小案例还是针对复杂度很高的商业项目都是有很强的实用性的嗯，最好大家各自提一些需求案例，然后看看用OO的方法进行分析设计会是怎么样的一个过程，跟以往的过程有些什么样的区别
---------------
到底什么是面向对象？
用户输入数据—>Test.aspx(Test.cs)—>TextBox.Text接收—>用DataInfo.cs保存—>在BLL.Data中处理逻辑—>用DAL.Data(调用DBHelper.cs)执行SqlCommand，这怎么就变成面向过程了？
---------------
就SkyIsland的疑问，我说说自己的看法做为一个编程菜鸟，我学习编程时首先考虑的是寻找最傻瓜化最自动化的工具来实现业务需求，如果有一台机器能够由我说一句“造房子”，再输入几个参数，它就能造出幢符合要求的房子来，那么只要综合成本被评估为“合理”，我就一定会买（或租用）这台机器，成本合理的情况下我是不会考虑自己动手或请施工队来盖房子的，然后我找到了ECO框架（版本是ECOIII），.NET环境下的一个ORM框架在ECOIII的框架下，我的工作思维模式是怎么样的呢？我描述出来跟SkyIsland的工作思维模式对比一下SkyIsland的开发过程：
用户输入数据—>Test.aspx(Test.cs)—>TextBox.Text接收—>用DataInfo.cs保存—>在BLL.Data中处理逻辑—>用DAL.Data(调用DBHelper.cs)执行SqlCommand我在ECOIII框架下的开发过程：
分析一个需求项目所涉及的对象->根据对象实例的共性提取实体类，确定实体类的属性与行为->根据实体类的共性提取抽象类，确定类的相互关系，描绘ER图与状态图->编译，ECOIII框架根据ER图与状态图自动生成基础代码->用对象查询语言（OCL）确定对象信息集控件（EH）获取的对象信息（可以是对象的基础信息或派生信息）->将界面控件与对象信息集控件相关联以获得系统的界面表达->编译运行程序，在界面中输入业务数据测试业务逻辑是否正确->业务逻辑测试完毕，将程序块打包->如果暂时没有数据持久化保存的要求的话，工作结束看到这里，可以发现我的工作过程中大部分的工作是在确定业务对象与业务逻辑----是不是更贴合“面向对象开发模式”这个词呢？？我的开发过程是不涉及数据库的，程序完成后，是可以运行在无数据库的环境下，既不涉及数据库文件，也不涉及数据库查询语言（比如SQL语言），只有当我们有保存数据的要求时（也就是有数据持久化的要求时）才会考虑到数据库那么当有人提出数据持久化的要求时，我会再做些什么呢？非常简单的事情，ECOIII提供了一个完全自动化的ORM环境，我所要做的就是给这个程序包加一个数据库映射控件而已，然后ECOIII根据所选择的数据库产品类型自动生成相应的数据库结构，现在再次运行程序，我所输入的业务数据就可以持久化保存了，数据库对我而言，不过是可以随时选择的存储介质而已，跟业务逻辑毫无关系，我的工作过程不再考虑表、表结构、表查询等等是什么东西，我考虑的基本上是“我要管理什么对象”、“我要取得什么对象的什么信息”这类事情，数据存储过程在我的工作过程中是由ECO框架自动执行的，我不需要考虑了事实上我本人到目前为止还没有学习过数据库知识，因为在ECOIII的环境下，我用不到数据库知识当然了，你也完全可以考虑自己搞个ORM框架，同样的，如果你搞出一个ORM框架，那么你的工作方式就应该是面象对象的分析、面向对象的设计，完成业务逻辑，然后将已完成的业务逻辑通过你的ORM框架挂接上具体的数据库也就是说，在面向对象的开发模式下，除了ORM（对象/关系数据库映射）工作以外的开发过程应该是与数据库零相关的，如果你所采用的开发环境包含有全自动的ORM能力，则你的开发全过程都应该是与数据库零相关的除了开发过程与数据库零相关，更重要的是，你工作的大部分内容应该是确定“我要管理什么对象”、“我要管理的各个对象之间的关系是怎么样的”，“我要取得什么对象的什么信息”如果没有类似ECO这样的自动代码工具，可能完全面向对象的开发过程会让程序员很不舒服，因为有人说按一个个类进行开发，代码量很大（真的吗？我没有经验不好下结论，有过对比经验的人来说一说），但在有自动代码工具的情况下，效率应该是极高的，事实上在ECOIII框架下开发，手工代码量是少的可怜的完全面向对象开发的另一大特点是，由于程序包跟数据库完全无关，任务分包可以分的非常清晰，一个大项目由N个小积木堆成的想法是可以实现的，同时一个项目需求分析出来的类不仅可以在同一个项目中的其它包里复用，而且可以在多个项目中复用，整个包也可以复用，假使需求有所变动，你最主要的修改工作将是去修改图纸，而不是去修改代码从公司的实践来看（我本身不是开发人员而是业务人员，但公司有正规的程序开发人员），面向对象的开发模式不管是针对复杂度很低的小案例还是针对复杂度很高的商业项目都是有很强的实用性的嗯，最好大家各自提一些需求案例，然后看看用OO的方法进行分析设计会是怎么样的一个过程，跟以往的过程有些什么样的区别
--------------------------------------------------
--------------------------------------------------
#41楼 2007-01-08 13:33 阿水
哈哈 讨论了很多了来一个业务吧，也是我们项目中实际的功能。
一个医药配送中心管理系统中有这样一个业务（客户提出，设计时没有）
仓库里的药品损益不直接修改库存，而是到另一个库存里（异常库存）
比如 报损10 那么 异常库存里就是-10 ，报益为正数。
现在 说异常库存里 有很多记录，有正有负。现在的要求是
把商品编号相同，但是批号不同的记录。数量能够正负抵消的
记录，生成一张单据。单据明细记录格式如下
编号 批号 数量
a 1 10
a 2 -10
......
我当时写这个功能
用PLSQL 写了 230行，声明了3个游标。
-----------------------------------------------
-----------------------------------------------
如果在EcoIII框架下来实现的话，过程如下：首先要对这个需求进行分析，看我们需要管理的对象是什么通过分析，我认为我们需要管理的对象是“药品”与“药品盘库损益记录”我们可以在Eco环境中画出4个类，并确定它们之间的关系 1、事物（抽象类）：
属性1：编号(interger) 2、药品记录（抽象类）：继承于“事物”
属性1：药品（值源自“药品”类实例的“编号”属性值）
属性2：批号(interger)
属性3: 发生数量(interger) 3、药品（实体类）：继承于“事物”
属性1：名称(string) 4、盘库损益记录（实体类）：继承于“药品记录” 然后在窗体中将一个对象信息集控件（EH）的OCL表达式设为："盘库损益记录.allinstances -> select(药品 = VH)" 这个OCL表达式表示----在全部“盘库损益记录”的实例中取得药品编号等于VH的实例集合（VH是动态参数控件决定的动态参数） 再将一个DBGRID与EH关联，另加个COMBOX控件用来选择“药品”，所得到的药品编号的值成为VH参数结果就是你在COMBOX里选择一类药品的编号，DBGRID就显示包含该药品编号信息的盘库损益记录，要更复杂一点，可以在尾行加上发生数量的合计数这样开发过程基本上就结束了，整个过程基本上是不需要编什么代码的，到此为止，开发过程还是与数据库无关的，但程序已经可以运行起来实现业务逻辑了ECO是自动ORM的，也就是说以上功能完成后，如果你希望输入的数据能持久化，那么加个数据库映射控件就可以了，你想挂DB2也行，挂ACCESS也行，挂ORACL也行，挂SQLSERVER也行
=====如果需求有变化，比如客户新增一个需求，要求有一个填制“盘库损益清单”的流程那么分析一下这个业务过程，可以知道我们要管理的对象比原来多了一个“盘库损益清单”（原来只是让大家填最简单的一条条的盘库损益记录）我们可以在项目的ECO框架中再画上一个新类盘库损益清单（实体类）：继承于“事物”
属性1：日期
属性2：仓库
属性3：盘点人
属性4：……然后为“盘库损益清单”与“盘库损益记录”这两个类画一条关系线，定义这二者为1对多的关系，意思就是一个清单可以包含多条盘库损益记录，一条盘库损益记录只能对应一个清单同样，编译一下，由ECO框架自动生成对应新的ER图逻辑的基础代码，再为项目添上几个对象信息集控件与几个界面控件，设置对象信息集控件的OCL语句以及与界面控件的关联关系，这个新增需求的开发过程就结束了可以发现，当开发过程中遇到需求有变化时，开发员的应变也很快速简单，因为不涉及数据库，只需要去修改业务逻辑就可以了这个新增需求完成后，业务逻辑的界面表现是-->新增一张清单，可以新增N条对应于该清单的损益记录，删除一张清单，对应于该清单的所有损益记录同时被删除，针对一张清单，可以一条条新增或删除损益记录，如果不存在任何清单，则不能新增损益记录事实上我一句代码也没写，就完成这个新增需求了BTW：刚挂了个ACCESS数据库试了下，发现设置类的时候，类及类的属性的NAME不能用中文（但可以在DBGRID中将CAPTION改成中文），否则生成数据库结构后保存业务数据时会报错，不过用XML文件保存数据的话，就没这个问题
不知你能否看明白我在12楼写的例子中描述的开发过程？？这样的开发过程，就是我所理解的全过程面向对象的开发模式我不用写一行代码就完成一个新增需求，无非是ECO的自动代码生成与自动ORM功能比较强，如果没有ECO，则需要完全用手工来做ECO帮我做的这些事，这应该是很累人的事，也可能正是因为大家一直没有拥有足够好的自动化代码及自动化ORM工具，所以会觉得完全的全程面向对象的开发会很麻烦当然很多人觉得麻烦的另一个因素则很可能是习惯问题，我对这样的工作模式比较能接受可能在于我没学过编程，没有你们的工作思维习惯，不管是面向对象还是面向过程，对于我而言，都是新东西，而在两种模式的比较中，我发现面向对象的模式更容易让我理解，而ECO这样的（或类似的）工具则让我较为轻松的完成实现工作微软好象也在搞ORM工具吧，有熟悉的可否也上来描述一下你们用其它的ORM工具进行开发的工作过程吧，我们可以借以做些工作过程的比较JAVA里不是也有个比较名叫Hibernate的ORM框架吗？你们使用JAVA开发时，是否也用这个框架呢？如果用的话，你们的工作过程是怎么样的呢？