爱华网C# 技术 2009-03-17 01:04:57 阅读371 评论0 字号：大中小订阅
我做的东西是完全按照微软的一些权威的例子做的，比如PetShop、Dowamishi、强类型、泛型集合、DBHelper.cs、UserInfo、BLL.User等等之类的概念，但是经理说这些东西都是面向过程的方法。
我不止一次的听别人说这些都是面向过程的方法，而且都是做了7、8年，上十年的技术主管、CTO、项目经理之类的人，他们基本都是在拥有500人以上的大公司里的，应该比较权威一点吧。
但是书上、网上很多文章都跟他们的说法背道而驰，我现在开始怀疑面向对象这个概念被升华得怎么神秘吗，连微软的那些例子都变成面向过程的方法了？
到底什么是面向对象？用户输入数据—>Test.aspx(Test.cs)—>TextBox.Text接收—>用DataInfo.cs保存—>在BLL.Data中处理逻辑—>用DAL.Data(调用DBHelper.cs)执行SqlCommand，这怎么就变成面向过程了？ 该回复于2008-04-14 18:30:17被版主删除 面向对象不是流程，而是一种看待事物的方式方法，是一种思想，一种思路，其实他们也不见得搞得清楚，时间长了你就有自己的理解了，他们说对，让他们坚持吧，项目还是要继续的 不用盲目追求面向对象，面向对象适合很多现实逻辑，但不代表适合所有逻辑
很明显，你用了类，你用了对象，你用的东西是面向对象的，但你自己写的东西是面向过程的
用组合模式封装，将DataInfo与BLL.Data与DAL.Data集成，形成一个逻辑处理类，但感觉与MVC模式背离。。。 其实petshop的模式有的地方是面向对象的，有的地方不是。换句话说，不能称之为面向对象。
1、数据库的设计，既然是数据库，他的设计方法就和面向对象设计相背离的。
2、petshop把一些数据表映射成了实体类，其实这也只是考虑了业务逻辑而已。
3、并不是说有了强类型、泛型集合、DBHelper.cs、UserInfo、BLL.User就是面向对象的，没有了就不是面向对象的，面向对象是一种思想，不是流程。面向对象包括面向对象的设计，面向对象的编码。
4、分层！=面向对象。 人人都知道是一种思想，能具体的描述吗，面向对象的设计，面向对象的编码，如何设计？如何编码？数据表映射实体类不是面向对象，那怎样做才是面向对象？我真得很想知道！ 你去理解一下面向对象的"简单工厂模式" ,简单工厂模式容易理解,所以建议你先看看.
我自己看过之后感觉自己写的代码差不多都是从VB里转来的,呵呵,差不多都是面向过程的.
因为没有用到封装,继承,抽象这些概念.一但熟悉了会发现原来代码可以这么写,哈哈,有些原来比较复杂,实现起来思路比较乱的,现在一分析感觉思路会很清晰. 我的理解,希望能够抛砖引玉:从某些角度来说,是一样的.比如面向过程，是函数调用,有了方法,面向对象,一般我们来做的也是函数调用.面向过程也可以实现多态,继承等,通过指针的操作,面向对象也是通过指针的操作来完成多态,继承等.从有些角度来看又不太一样,面向过程是一个流程,面向对象是一种抽象.设计模式看看就稍微明白点,就了解对象和过程还是有区别的.
我以前也完全不明白,后来做的点项目,才稍微入了点门. 我总结一下大家的发言：
1. 面向对象是一种思想。
2. 面向对象是一种抽象。
3. 面向对象就是封装、继承、多态。
4. 有数据库的程序 != 面向对象。
5. 数据库映射实体类 ！= 面向对象。
6. 分层 ！= 面向对象。
但是大家都说得很空洞，让初学者难以揣摩，有人能结合一个实例说明一下吗，如何设计？ 编程里，把什么都看成对象，甚至是变量。比如说猫类在动物界是一种类型,而对象就相当于这个猫类中的某一只猫,例如cat这只猫,就是猫类的这个类型的一个对象. 打个比方，让你编一个计算正方形的程序，一般的思路是：
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类 引用 18 楼 TLJewel 的回复:
打个比方，让你编一个计算正方形的程序，一般的思路是：
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类
你这样的例子没用！比如说我做一个网站，而这个网站里有个计算正方形面积的功能，我完全可以像你说的用一个Square类来表示正方形，长、宽是属性，计算面积是方法，然后我从保存“形状”的数据表中取出一个正方形，然后通过Square类计算它的面积，然后返回到网站的用户界面上显示面积的结果。
这跟我说的网站设计的那个流程有什么区别？从宏观角度来说，也是数据的提交和回送。只不过是多了一个用“类”来表示对象的方式，任何初学者完全都可以用你这样的思路来设计，但是照样被人指成是“面向过程”。 看来你真的没明白对象。
从结果来看任何程序都是过程的，因为从数据输入-查找运算-显示结果肯定是一个具体的过程。
对象实际上一种编程思想，而并非啥Bil，Dal层，那个是对象的结果而已。
实际对象说穿了就是封装变化和类重用。而不是啥3层N层。 对于上面那个例子，实际上人家的类的本意是
如果要计算面积话，这个类肯定要有技算参数和计算方法两种东西存在
无论是圆也好，还是方也好。但是这个具体的计算则需要看具体是技算圆还是技算方
那么圆和方的面积计算的变化点在那里，就在上面红字的地方。于是对象的结果就成了
创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
比方说我做一个工资管理系统，我要通过一些参数来计算出员工的最终工资。那么我就做一个工资类，然后在里面放一个通过各种参数来计算工资的方法，需要调用的时候就实例化工资类，然后调用这个工资计算方法，我肯定不会在Page_load中一行一行那样从上向下一直写下来。
也就是说，我采用的方法跟你采用的方法是一致的，你觉得那里有问题？ 如果，你明白上面说的封装变化和类重用这两点的话，你就算明白对象了
这也是为什么新手写东西常常被认为是过程原因，虽然从语言层面上看他们也用object，也继承，也封装，也多态。但是他们不明白变化点在那里，他们做不到类重用。
呵呵，对象实际不适合新手，只有有经验的人才明白在项目里那些是公用的，那些是变化的。对象存在的目的只有一条---防止变化，应对变化，以达到代码复用，让程序员不再重复劳动（呵呵，老油条定义就是有经验而且会偷懒） 引用 19 楼 SkyIsland 的回复:
引用 18 楼 TLJewel 的回复:
打个比方，让你编一个计算正方形的程序，一般的思路是：
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类
你这样的例子没用！比如说我做一个网站，而这个网站里有个计算正方形面积的功能，我完全可以像你说的用一个Square类来表示正方形，长、宽是属性，计算面积是方法，然后…
你这样想还是面向过程的想法，面向对象说穿了就像 wanghui0380 说的那样就是封装变化和类重用。
举个例子来说吧，你要在网站增加个log功能，如果你是已面向过程的想法可能就是这样
C# code public class Log { public void Write(string loginfo) { //具体的实现,假如说是写入到数据库中 } }
然后你就在各个需要用到log功能的地方增加
Log log = new Log();
log.Write("信息1");
你看看，这段代码中有class吧，也解决了实际的问题了，但你这就是面向对象了吗？
这时候项目要求变化了，要将原来要存入数据库中改为存入文件中，你就会发现需要修改代码了，不过简单！将Log中的Write修改一下就可以了。
接着项目需求又变了，Log有的地方要存到数据库中，有的地方要存入文件中，又要改代码了，怎么改呢，像这样改？
C# code public class Log { public void WriteDataBase(string loginfo) { //具体的实现,假如说是写入到数据库中 } public void WriteFile(string loginfo) { //具体的实现,假如说是写入文件中 } }
你会发现噩梦来了，你需要修改散落在项目中成千上万个调用的代码，即使你修改好了，那以后呢？需求又变化了呢？
你会想为什么会出现这样的问题，我不是也使用了对象了吗？甚至我的项目也使用到了分层了呀？难道不是面向对象吗？
没错，你是使用了这些时髦的技术，什么反射啊，分层啊，封装、继承、多态你都很熟悉，但你的思路仍然处在面向过程之中，你只是以面向过程的思路来解决问题而已 引用 22 楼 SkyIsland 的回复:
比方说我做一个工资管理系统，我要通过一些参数来计算出员工的最终工资。那么我就做一个工资类，然后在里面放一个通过各种参数来计算工资的方法，需要调用的时候就实例化工资类，然后调用这个工资计算方法，我肯定不会在Page_load中一行一行那样从上向下一直写下来。
也就是说，我采用的方法跟你采用的方法是一致的，你觉得那里有问题？
问题还是在于变化！
普通工人的工资
管理人员的工资
工资的计算方式
他们有相同的地方，有不同的地方
过程的方式就是管理人员的工资写一个函数，普通的人员在写一个函数，这个不用考虑啥，反正具体问题具体对待，如果方式变了，大不了改改函数，或加几个函数
而对象设计人员考虑问题的方式是：既然有管理和工人，那么其他类型呢？销售人员，股东----
工资计算：按件，按等级，按工龄
实际是做对象的人，首先考虑的是变化，明白了。所以他们构造对象时候，会把变化留出来。 非常感谢[一水寒]的指点。
你的讲解给我的第一印象是，需求无限的变化，而我们要考虑未来的变化来设计现在的东西。是啊，怎么办呢？如果未来有100种需求，难道我们现在就要事先想好所有的变化吗？对于这方面您有什么好的想法？
我现在只能通过无限修改代码的方式来解决这个问题，比如说，有一张表，你通过子查询的方式可以有千变万化的View，用户今天要一个View，我加一个，明天又要另一个View，我又加一个。目前为止，我只能这样做了。
也非常感谢[放歌]说了那么多经验，我好像有点茅塞顿开，但只是略微的，可能需要经过几次实践才能领悟。
你说出了[一水寒]那个问题的答案，不，是一个思路——留出了变化空间。
呵呵，可能我有点贪婪，我迫切的想知道如何留出变化的空间。 这要说明清楚的话没一本书是说不完的，楼主可以看看设计模式这本书，就是在说明这个问题。
OO设计要遵循5大原则：
1、开闭原则(OCP);
2、里氏替换原则(LSP);
3、单一职责原则(SRP)；
4、依赖关系倒置原则(DIP)；
5、接口隔离原则(ISP)
这些网上大把的文章来说明，
我刚才看了开闭原则的描述，有一个疑问。
开闭原则说，不能直接在具体类上修改，但可以继承抽象类或实现接口，但是继承抽象类或实现接口不也是要添加代码吗，如果需求无止境的改变，那我不是要无止境的继承，无止境的实现接口？ SkyIsland
如果需求一直在改，项目有可能会做死，这就是为什么项目成功率不高的原因，主要原因就是客户需求不断变化，而设计人员设计的系统不足以承受这种变化。
//
开闭原则说，不能直接在具体类上修改，但可以继承抽象类或实现接口，但是继承抽象类或实现接口不也是要添加代码吗，如果需求无止境的改变，那我不是要无止境的继承，无止境的实现接口？
//
开闭原则不是说不添加代码，而是不对以前的代码再做修改，在已有的类和接口上实现。
如果需求无止境的改变，那么你只需要实现必要的接口或者继承抽象类。
至于说需求一直改变，甚至改变到和原来的项目一丝边都不挨的时候，恭喜你，你的项目失败了，重新设计，因为这是另外一个项目了。楼上机会说的需求改变，开闭原则都是在一个产品可以改变的范围内，比如工资计算方式变了，比如什么什么的，而你忽然增加了N个风牛马不相及的东西，能一样吗？ 引用 25 楼 wanghui0380 的回复:
引用 22 楼 SkyIsland 的回复:
比方说我做一个工资管理系统，我要通过一些参数来计算出员工的最终工资。那么我就做一个工资类，然后在里面放一个通过各种参数来计算工资的方法，需要调用的时候就实例化工资类，然后调用这个工资计算方法，我肯定不会在Page_load中一行一行那样从上向下一直写下来。
也就是说，我采用的方法跟你采用的方法是一致的，你觉得那里有问题？
问题还是在于变化！
普通工人的工资
管理人…
赞同，现在的面向对象的许多思想，都是为了适应需求的变化。
面向过程的思路在针对具体的问题上是可以与面向对象一样解决问题的，但是，若采用面向对象的思路，将能设计出更加适合需求变化的软件，降低软件的后期维护成本和难度。
也正是因为这样，新手往往不知道如何使用面向对象的思想，都陷入了面向过程的境地，这些的改善只能是多积累经验，多看好的代码，多实践。 你话可不能这样说啊。
1.开闭原则的目的是什么？不就是为了减少修改吗？减少修改的目的不就是为了减少新增的代码量吗？如果一个功能需要改，可能用开闭原则添加的代码量比不用开闭原则的还要多，因为你要新继承一个类，而在原来类的基础上改只需要增加一个方法。如果每个星期需求改变一次，连续三个星期改三次，用开闭原则我就要新增三个继承的类，而不用开闭原则，我只用新增三个方法就行了。这样的话，开闭原则就失去了意义。你说一个项目需求变更太多了就是失败的项目，就算我只变一次，用开闭原则比不用开闭原则的新增代码量还是多一些。
2.我曾经看过别人做一个上海某区的区政府项目，那个需求基本是3天一变，而且每次变都是大规模的变，因为最终用户有3000人，40个部门，每个部门的看法都不一样，甚至每个人的看法也都不一样。（同一个功能）这是一个现实问题。
按照[一水寒]的说法，只能是避免修改了方法名产生了维护困难。
不好意思，我不是故意想找碴，我是想尽量深入的探其究竟。而且在现实中，我遇到的项目基本都是需求要变几十上百次的。我想，我们不应该逃避这个残酷的社会现实吧？请指点！ 37楼我都看了，总是被楼主的问题难住，原来我也不懂得面向对象编程啊，面对需求的改变，到底是在原有的类里加一个方法，还是在总体的框架下加一个类呢？
可是如果一直在一个类里加方法的话（往一种极端推理），按理说一个项目有一个类就够了，每个功能对应一个方法，难道这就是面向过程啦？
如果碰到需求改变，之前的类不动，新加类（再极端一下），一个项目N多类，每个功能对应一类，而每个类却只有一个方法，难道这就是面向对象？
面向对象是一种抽象，那抽象的实现不就是面向过程吗？做开发的考虑的不就是怎样实现吗？是不是做一做项目经理就能理解什么是面向对象啊？呵呵...自言自语了。
以上的是我自己遇到的问题，希望不会影响本帖的思路，我占个位子继续学习。 面向对象这个词语，我觉得应该从三个方面来考虑。第一是它的概念。第二是它的实现方法，第三是它的目的。
概念大家都清楚，而它的实现也很简单，无非就是封装、继承和多态。它的目的是什么，前面已经有人提到了，就是如何从容的面对变化。程序员每天的生活就是面对变化、解决变化。
“面向对象”和“面向过程”孰优孰劣关键取决于项目的需求。一般来说，前期适合用面向过程的方式去解决用户的需求，然后到了项目后期，进行代码重构，一直到项目结束。在项目结束后，好好的总结一下，将以前的代码和设计拿出来仔细的看看，然后静心的想想还有哪些地方值得优化、哪里的设计还存在问题。这样做过几个项目的话，“面向对象”的思想也就差不多掌握了。
面向对象会衍生出“模式”，“模式”是将面向对象进一步封装。在特定的场合特定的需求下使用模式。四人帮的23种模式并非一成不变，他们只是前人经验的总结而已，根据自己项目的特点进行改造。
面向对象和模式都是一种思想，而思想的掌握要求自己深入的思考和理解，这感觉跟“悟道”一样，也许有一天，你一下子就明白了，如同拨云见日一样，这就是“顿悟”。 无论是C++、C#、Java的“this”、Delphi中的“Self”、VB.NET中的“Me”
这些为面向对象而设计的语言都少不了“自己”这个概念
当然“自己”也是要被抽象的，所以也都少不了“class”
思考问题的方法不限于某个领域更不限于某种语言，哪怕是用汇编也能实现面向对象的开发。 引用 23 楼 wanghui0380 的回复:
如果，你明白上面说的封装变化和类重用这两点的话，你就算明白对象了
这也是为什么新手写东西常常被认为是过程原因，虽然从语言层面上看他们也用object，也继承，也封装，也多态。但是他们不明白变化点在那里，他们做不到类重用。
呵呵，对象实际不适合新手，只有有经验的人才明白在项目里那些是公用的，那些是变化的。对象存在的目的只有一条---防止变化，应对变化，以达到代码复用，让程序员不再重复劳动（呵呵，老油条定…
我也觉得封装变化和类重用是面向对象的重点，不过要做到也不容易。 引用 3 楼 lake_cx 的回复:
不用盲目追求面向对象，面向对象适合很多现实逻辑，但不代表适合所有逻辑
很明显，你用了类，你用了对象，你用的东西是面向对象的，但你自己写的东西是面向过程的
用组合模式封装，将DataInfo与BLL.Data与DAL.Data集成，形成一个逻辑处理类，但感觉与MVC模式背离。。。
三楼说的好，用的东西是面向对象的，但自己写的东西是面向过程的
唉，面向对象这东西看起来容易，用起来难
我觉这个有些道理，我觉得我们一直在用面象对象，但是做得不够好，考虑不周到，
但万事怎么就一定能做到十全十美呢？社会在发展，需求在不断改变，就算能预知十年的需求，也不能说是完美的，相对而言嘛！ 跑题了跑题了，本来是讨论面向对象的，怎么跑到客户和需求上去了？
客户是魔鬼，上帝也好，需求是地狱，天堂也罢，和面向对象没什么关系吧，你就是用机器语言写出来的程序客户用的舒服，夸赞不已，那照样会是天堂的。 总结大家的发言：
1.OO是一种思路。
2.OO是一种抽象。
3.OO不是万能的。
4.使用了OO的概念，但并不代表就有了OO思想。
5.数据库的设计!=OO
6.数据表映射实体类!=OO
7.分层!=OO
8.OO就是封装、继承、多态。
9.学习设计模式有利于理解OO。
10.OO是目的是“封装变化”和“重用”。
11.OO的设计思路是要把“变化”留出来。
12.如果需求改得乱七八糟而导致无法维护就等于设计失败。
13.学习OO的方法要多实践、多参考、多积累。
14.开闭原则的疑惑：新加类好，还是新加方法好？
15.对于初学者，项目初期为了提高开发速度，先使用面向过程进行，项目快结束时来一个“重构”。
16.没有OO特征的编程语言也可以用OO思想开发。
17.封装和继承很容易弄懂，明白多态才能真正明白OO。
18.建议看《C# OBJECT从概念到代码》。 就是2个人在生孩子。。。然后越生越多。。。就成了人类。。
然后人类创造了很多东西。。就成了世界。。
把所有类想成是人，人有不同的属性，但是有固定的父母
事件函数就是人的能力和拥有的东西。。
哈哈。。我现在的抽象化的理解。。不知道是不是很傻啊。。。 有点偏激了。看大体，不要看局部。不过说实话有时我也有同感。慢慢吸收吧！每个人的定位不同。评价也不同。 引用 16 楼 SkyIsland 的回复:
我总结一下大家的发言：
1. 面向对象是一种思想。
2. 面向对象是一种抽象。
3. 面向对象就是封装、继承、多态。
4. 有数据库的程序 != 面向对象。
5. 数据库映射实体类 ！= 面向对象。
6. 分层 ！= 面向对象。
但是大家都说得很空洞，让初学者难以揣摩，有人能结合一个实例说明一下吗，如何设计？
好多人在会手概念而已,其中不理解面向对象的大有人在,工作时候很多都不管什么对象和过程了.
其实我和你一样,也想弄明白这个玩意,可是让很多人来说,一样说不出个所以然来,看来很多东西一个是经验的积累,
一个是自己多研究了.
1.我们只是举一个局部的例子来讨论大体，因为布局例子比较好举，大体的例子怎么举？
2.往往实际的问题都出在局部，而不是大体。
3.循序渐进的学习，从局部到大体，而不是倒过来学。 需求无限的变化，而我们要考虑未来的变化来设计现在的东西。是啊，怎么办呢？如果未来有100种需求，难道我们现在就要事先想好所有的变化吗？对于这方面您有什么好的想法？
面向过程关注业务流程。设计跟着流程走，流程一旦改变，代价很大，甚至要重写；而面向对象关注对象，比如这个业务牵涉到了男人，电脑，就设计男人，电脑两个类（也许还有人这个抽象类），然后定义类的属性，行为啥的。以后如果他们有任何业务关系（男人和电脑），都可以适应了。
一点薄见，高手很多，战战兢兢，不敢多方。 引用 24 楼 yunfeng007 的回复:
引用 19 楼 SkyIsland 的回复:
引用 18 楼 TLJewel 的回复:
打个比方，让你编一个计算正方形的程序，一般的思路是：
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类
你这样的例子没用！比如说我做一个网站，而这个网站里有个计算正方形面积的功能，我完全可以像你说的用一个Square类来表示正方形…
我也是一个初学者，对于这个例子我是这样理解的。如果用面向过程的方法。如下
一开始：
public class Log
{
public void Write(string loginfo)
{
//具体的实现
}
}
要用到的地方：
public class a
{
public void method1()
{
Log x=new Log();
x.Write("222");
}
public void method2()
{
Log x=new Log();
x.Write("222");
}
public void method3()
{
Log x=new Log();
x.Write("222");
}
public void method4()
{
Log x=new Log();
x.Write("222");
}
}
后来：
public class Log
{
public void WriteDataBase(string loginfo)
{
//具体的实现,假如说是写入到数据库中
}
public void WriteFile(string loginfo)
{
//具体的实现,假如说是写入文件中
}
}
每一个地方都要修改：
public class a
{
public void method1()
{
Log x=new Log();
x.WriteDataBase("222");
}
public void method2()
{
Log x=new Log();
x.WriteFile("222");
}
public void method3()
{
Log x=new Log();
x.WriteDataBase("222");
}
public void method4()
{
Log x=new Log();
x.WriteFile("222");
}
}
现在把不变的地方提出来，写一个接口：
interface Log
{
void Write(string loginfo);
}
public class MyLog:Log
{
public void Write(string loginfo)
{
//具体方法
}
}
用一个简单工厂：
public class LogFactory
{
public Log GetLog(int LogNumber)
{
Log x;
switch(LogNumber)
{
case 1:
x=new MyLog();
break;
}
return x;
}
}
客户端：
public class a
{
public void method1()
{
Log x=(new LogFactory()).GetLog(1);
x.Write("222");
}
public void method2()
{
Log x=(new LogFactory()).GetLog(1);
x.Write("222");
}
public void method3()
{
Log x=(new LogFactory()).GetLog(1);
x.Write("222");
}
public void method4()
{
Log x=(new LogFactory()).GetLog(1);
x.Write("222");
}
}
将来变了，只要加一个类，实现接口Log:
public class MyLog2:Log
{
public void Write(string loginfo)
{
//具体方法2
}
}
简单工厂里改一下：
public class LogFactory
{
public Log GetLog(int LogNumber)
{
Log x;
switch(LogNumber)
{
case 1:
x=new MyLog();
break;
case 2:
x=new Mylog2();
break;
}
return x;
}
}
客户端：
客户端：
public class a
{
public void method1()
{
Log x=(new LogFactory()).GetLog(1);
x.Write("222");
}
public void method2()
{
Log x=(new LogFactory()).GetLog(2);
x.Write("222");
}
public void method3()
{
Log x=(new LogFactory()).GetLog(1);
x.Write("222");
}
public void method4()
{
Log x=(new LogFactory()).GetLog(2);
x.Write("222");
}
}
这里GetLog方法的参数还要改，但可以想办法用反射消除。但前提是程序员要先预知这个地方存在改变的可能，先留了空间。
对设计模式一直一知半解，在就用的时候就不行了，还望各位前辈指教。 引用 81 楼 netone04 的回复:
需求无限的变化，而我们要考虑未来的变化来设计现在的东西。是啊，怎么办呢？如果未来有100种需求，难道我们现在就要事先想好所有的变化吗？对于这方面您有什么好的想法？
面向过程关注业务流程。设计跟着流程走，流程一旦改变，代价很大，甚至要重写；而面向对象关注对象，比如这个业务牵涉到了男人，电脑，就设计男人，电脑两个类（也许还有人这个抽象类），然后定义类的属性，行为啥的。以后如果他们有任何业务关系（男人和电脑），都可以适应了。
一点薄见，高手很多，战战兢兢，不敢多方。
是啊，对象已经设计好了，不用改了，但是需求改变，需要改那里呢？总要有一个地方要改吧？只要有一个地方要改，就需要添加代码，这也是工作量增加，用面向过程的思路去做也是要改那些地方，增加的代码量一样，工作量一样，你用面向对象的思路去改要加班一通宵，用面向过程的思路同样是一通宵了。 呵呵，楼上的谦虚过度了，学习嘛，放开胆量的说，讨论越激烈越好，最好吵起来，结果很快会出来。 10.OO是目的是“封装变化”和“重用”。
11.OO的设计思路是要把“变化”留出来。
封装变化OO的都说， 那究竟怎样封装变化呢？为什么要封装变化呢？关键在于我们得要抓住变化在哪里，这个取决于我们的技术、经验和对系统的理解。如果变化只是一个函数的行为，那么一个模板的方法即可满足了我们的要求，而变化的是一个事物或者一个构件的行为，那我们可能就要进行类的组合来完成接口设计
14.开闭原则的疑惑：新加类好，还是新加方法好？
我们的设计应该对修改说 关闭，对扩张说 打开
没有一个模板能够适应所有的情况，任何一个都会变化，不可能完全封闭
对程序中的每一个部分都进行抽象不是一个好的习惯，正确的做法应该是仅仅对频繁变化的部分做抽象，我们要拒绝不成熟的抽象设计
--是啊，对象已经设计好了，不用改了，但是需求改变，需要改那里呢？总要有一个地方要改吧？
这是针对设计的角度来讲的，即OOA，OOD的时候，关注的重点是对象，而不是流程。（面向过程在分析的时候，会主要关注先怎么样后怎么样，OO则有哪些对象参与，各对象有啥特性，能干啥，他们之间发生了什么）
在设计的时候应尽可能考虑到变化，所以有时要用到抽象（类是具体业务对象的抽象，抽象类是类的抽象，接口是方法的抽象），开闭原则（修改的时候对新增开放，对修改关闭）。设计模式就是围绕着封装变化而讲的。
面向对象的对象（类）是和现实业务中的对象对应的，所以从理论上说可以描述现实生活中的一切活动和流程。呵呵，类似仿生学。 面向对象是你思考问题的方式, 如果你用面向过程的思想来思考,再用C#对着老虎画画,最后画出来还是猫,你说不上为什么是猫,但确实是猫.就像现在一个白老虎和一个有斑纹的白猫在你面前,你能分辨出来,但是很难说清楚.
这就是大部分程序员喜欢从语法的层次来理解面向对象,看见一票class就是面向对象了...其实是用面向对象的皮包裹着过程的思想.
从上面一楼的简单描述,我能感觉到你没有理解面向对象. 因为你把面向对象跟流程给混一起了,这其实是不相干的事情. 目前只能理解到：
如果说话不方便，那么首先，
把名词看成名词，把动词看成名词，把形容词看成名词……（封装）
一切都成为名词后，
把a名词和b名词[c名词……]看成同一个词（抽象）
一切都成为好用的基本词汇后，
在相近的场合跟人家说基本词汇，听者自己会理解这个基本词汇表达的意思（多态）
如果比较懒或场合需要，利用基本词汇组合成能很好地表达意思的新词用用（继承）
很傻的理解，见笑了。
面向对象.
对象,假如别人问你,你有没有对象,你的回答是有和没有,那么对象是什么呢?
面对对象思维不但在程序这个领域,当然我们要说的是领域,
一个网站和一个系统,用户是一个必要的因数,我们可以把用户说成是一个对象.
对象有什么呢?在程序里面有属性和方法,用户的名字,密码,Email等等,都是他的属性,方法呢?
注册,登陆,修改等等,这些都是用户这个对象的方法.
我觉得,面对对象不必很刻意的去学习.在平时想想,这个是不是可是说一个对象?假如可以,那么它的属性和方法呢?
面向对象有三大特征:继承,封装,多态.
理论上的东东,我也晕乎乎的.
我最大的一个体会就是,对象,不管里面的过程和方法什么的,只要吧必须的条件放进去,拿出自己要用的对象,和它的方法,属性等等,我就让这个对象给我服务了..嘎嘎. 面向对象其实很简单，不要用程序语言去了解程序，结合现实的生活，从另一面去看，就很简单了
面向对象就是把程序中的每一个操作都当作是对象（个体）的方法，就像人会开车一样，人就是对象， 引用用户输入数据—>Test.aspx(Test.cs)—>TextBox.Text接收—>用DataInfo.cs保存—>在BLL.Data中处理逻辑—>用DAL.Data(调用DBHelper.cs)执行SqlCommand，这怎么就变成面向过程了？
这种被叫做 数据驱动方式, 还是过程方式 引用 69 楼 viki117 的回复:
就是2个人在生孩子。。。然后越生越多。。。就成了人类。。
然后人类创造了很多东西。。就成了世界。。
把所有类想成是人，人有不同的属性，但是有固定的父母
事件函数就是人的能力和拥有的东西。。
哈哈。。我现在的抽象化的理解。。不知道是不是很傻啊。。。
用户输入的数据应该要形成一个有血有肉的对象, 而按照楼主那种方式最终目的只是调用DBHelp把它保存到数据库中, 被叫为数据驱动
比如说注册吧, 应该这样, 用户填写完成-->Test.aspx(Test.cs)—>TextBox.Text接收-->UserService中生成User对象, User对象本身的逻辑要写在User.cs里面, 与其它模块相关的逻辑写在UserService.cs里, 然后调用DBHelp保存对象
可以理解成 UserService和User对象封装了一个完整的领域模型, 给控制层提供服务, DBHelp只是个工具 引用 111 楼 japan_as_sb 的回复:
引用用户输入数据—>Test.aspx(Test.cs)—>TextBox.Text接收—>用DataInfo.cs保存—>在BLL.Data中处理逻辑—>用DAL.Data(调用DBHelper.cs)执行SqlCommand，这怎么就变成面向过程了？
这种被叫做 数据驱动方式, 还是过程方式
这种方式用UMl解释话，这个叫做序列图。而做对象分析的更关心类图，而做测试的则关心用例图（实际上对象分析人员也用用例图，因为要根据用例图来提炼出对象） 我转一个帖子好了
面向对象的思维方式：
面向对象是围绕对象和类来分析、设计软件系统的。
面向对象分析：
面向对象分析的主要任务是根基用户的需求，建立一个准确的、完整的、一致的系统模型。在面向对象的分析过程里，项目
组通过分析软件的功能性需求，得到一个理想化的系统模型，该模型更多的侧重于描述我们需求解决的问题是什么---我们称这种模型为分析模型。
面向对象分析与面向对象设计的区别:
1、在侧重点上，面向对象分析侧重于理解问题，描述软件做什么，而面向对象设计侧重于理解解决方案，描述软件如何做。
2、面向对象分析一般只考虑理想的设计，不关心技术和实现的细节，而面向对象设计更具体、更详细、更接近真实的代码的设计方案。
3、在设计结果的描述方式上，分析阶段侧重描述对象的行为，设计阶段侧重于描述对象的属性和方法。
4、面向对象分析只关注功能性需求，而面向对象设计既关注功能性需求，也关注非功能性需求。
5、面向对象分析的产生的系统模型通常规模较小，而面向对象的设计产生的系统模型规模较大，内容也比较完整、详尽。
用例驱动的面向对象分析：
面向对象分析的过程包括：
1、从用例中提取实体对象和实体类。
提取实体对象的方法，依据用例描述中出现的名词和名词短语来提取实体对象，必须对原始的名词和名词短语进行筛选。
得到实体对象后，对实体对象进行归纳、抽象出实体类。
2、提取属性
3、提取关系
4、添加边界类
5、添加控制类
6、绘制类图
7、绘制顺序图
8、编制术语表
上面这个说明基本表明了一个做对象的人都在干嘛！看的出来，做对象的人首先干的事情不是编码，而是设计一个模型和规范。而上面说的两种人的区别只是颗粒度的问题，做分析的颗粒度大些，做设计的颗粒小些。 我对面向对象的理解就是在一切变化中找到不变的东西,用不变的东西进行程序设计,改变具体的实现而不动整体的结构,个人浅见,大家别扔板砖
男人--->小男人--->大男人---->老男人
人类---->
女人--->小女人--->大女人---->老女人 SRP 单一职责原则：就一个类而言，应该仅有一个因其它变化的原因。
OCP 开放-封闭原则：软件实体（类、模块、函数）应该是可以扩展的，但是不可修改。
LSP Liskov替换原则：子类型必须能够替换掉它们的基类型。
DIP 依赖倒置原则：抽象不应该依赖于细节。
ISP 接口隔离原则:不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
REP 重用发布等价原则：重用的粒度就是发布的粒度。
CCP 共同封闭原则：包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其它的包不造成任何影响。
CRP 共同重用原则：一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。
ADP 无环依赖原则：在包的依赖关系图中不允许存在环。
SDP 稳定依赖原则：朝着稳定的方向进行依赖。
SAP 稳定抽象原则：包的抽象程度应该和其稳定程度一致。
-------摘自《敏捷软件开发-原则、模式与实践》 OO的核心是抽象
所谓的类，顾名思义就可以知道是个抽象的概念
一定要弄明白多态的概念，真能真正理解OO
而封装与继承只要智商不是太低很容易理解~
顶这个
用了快2年的C#啦，才明白：OO不是说懂就懂了的！
也许我们都懂c#，对其语法也很精通了。然而只有亲自动手把复杂的现实OO出来，
并实现只有才能真正体会OO。
有一句诗形容非常好：
不识庐山真面目，只缘身在此山中
强帖留名，41的话是至理名言 OO的核心是抽象
所谓的类，顾名思义就可以知道是个抽象的概念
一定要弄明白多态的概念，真能真正理解OO
而封装与继承只要智商不是太低很容易理解~
顶这个
我也顶这个，实际上多态正是解决变化的手段，而设计模式则是管理和调控由于继承，多态造成的千奇百怪的类的手段。 面向对象是一种思想，这种思想应用到编程中的三大特点就是：Encapsulation,Inheritance及Polymorphism;这三大特性要在实践中慢慢体会 引用 104 楼 zhenghaibingood 的回复:
目前只能理解到：
如果说话不方便，那么首先，
把名词看成名词，把动词看成名词，把形容词看成名词……（封装）
一切都成为名词后，
把a名词和b名词[c名词……]看成同一个词（抽象）
一切都成为好用的基本词汇后，
在相近的场合跟人家说基本词汇，听者自己会理解这个基本词汇表达的意思（多态
