一 : 什么叫做面向对象?
什么叫做面向对象?
什么叫做面向对象?
面对对象就是：
把数据及对数据的操作方法放在一起，作为一个相互依存的整体——对象。对同类对象抽象出其共性，形成类。类中的大多数数据，只能用本类的方法进行处理。类通过一个简单的外部接口与外界发生关系，对象与对象之间通过消息进行通信。程序流程由用户在使用中决定。
面向过程就是：
自顶向下顺序执行，逐步求精；其程序结构是按功能划分为若干个基本模块，这些模块形成一个树状结构；各模块之间的关系尽可能简单，在功能上相对独立；每一模块内部均是由顺序、选择和循环三种基本结构组成；其模块化实现的具体方法是使用子程序。程序流程在写程序时就已决定。
二 : 摘，值得深思——“到底什么叫做面向对象？自认为搞清楚了，可是经理说我没搞清楚。”
摘，值得深思——“到底什么叫做面向对象？自认为搞清楚了，可是经理说我没搞清楚。”
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名词……]看成同一个词（抽象）
一切都成为好用的基本词汇后，
在相近的场合跟人家说基本词汇，听者自己会理解这个基本词汇表达的意思（多态）
如果比较懒或场合需要，利用基本词汇组合成能很好地表达意思的新词用用（继承）
很傻的理解，见笑了。
看看对不对。
商场收费系统：
收费方式
普通收费:收费方式
打折收费:收费方式
返利收费:收费方式 对象分析一般从一个具体用例描述开始
比如：
收银员根据顾客选购的商品收费
这个就是一个具体用例。
首先分析名词：
收银员 顾客 商品
然后是动作：
计算费用并收费
然后是限定
操作人员--收银员，管理人员，定价人员，会计，仓管人员
商品-普通商品，折扣商品
顾客-普通客户，普通vip客户，大集团客户
接着是控制：
商品价格控制
顾客类型控制
最后是关系
商品价格由具有该权限的人员管理
费用由顾客类型决定
于是最终设计可能就为
操作人员类（这里可能是一个工厂类）
顾客类（这里也可设计成工厂类）
商品类（一个商品可能根据顾客不同而有不同的价格，所以这里可能是个装饰类）
费用计算类（限定接口，只允许接收顾客和商品列表两参数，以保证最终调用者始终只有一种调用方式）
我这里只是一个简单的分析，我为了描述上的简单把实体类和控制类合并了，不过如果是了解设计模式的人估计是看的明白的。
面向对象就是让你当领导，只告诉手下做什么，不管他怎么做，用什么方法……比如说把我的孩子接回来，不管他是去背回来还是开车接回来，还是他再派人接回来，只要吧孩子接回来就行^…… 引用 104 楼 zhenghaibingood 的回复:
目前只能理解到：
如果说话不方便，那么首先，
把名词看成名词，把动词看成名词，把形容词看成名词……（封装）
一切都成为名词后，
把a名词和b名词[c名词……]看成同一个词（抽象）
一切都成为好用的基本词汇后，
在相近的场合跟人家说基本词汇，听者自己会理解这个基本词汇表达的意思（多态）
如果比较懒或场合需要，利用基本词汇组合成能很好地表达意思的新词用用（继承）
很傻的理解，见笑了。
我觉得蛮贴切 的啊！！！！！！ 前天本来看了一下这个帖子，不过当时不知道怎么说好
今天从头看了一遍，真热...
上次去面试，还就是这个题目，让我讲一下面向对象，觉得真说不清，因为这是一系列的思想，给大家看一下我学习的参考资料吧
参考资料
林锐:《修练8年C++面向对象程序设计之体会》
中程在线:面向对象
林锐老师讲的挺好
继承的场合
若在逻辑上B 是A 的“一种”（a kind of ），则允许B 继承A 的功能。如男人（Man）是人（Human）的一种，男孩（Boy）是男人的一种。那么类Man 可以从类Human 派生，类Boy 可以从类Man 派生。
组合的场合
若在逻辑上A 是B 的“一部分”（a part of），则不允许B 继承A 的功能，而是要用A和其它东西组合出B。例如眼（Eye）、鼻（Nose）、口（Mouth）、耳（Ear）是头（Head）的一部分，所以类Head 应该由类Eye、Nose、Mouth、Ear 组合而成，不是派生而成。
我总结了几个概念
1、将性质相同的对象进行抽象，这个抽象的过程就是类的设计；
2、对象B是对象A的特定一种，那么我们可以设计B继承于A；
3、对象A有部件B、C等，那么我们设计时可以将B、C组合形成A;
4、多个对象具有相同的方法、属性定义，但具体的执行情况不同，这样我们称之为对象的多态；
类设计的求同存异
求同：就是将性质相同的对象进行抽象，这个抽象的过程就是类的设计，结果就是类的定义
存异：某类对象A中的某些成员B具有与其它成员不同的性质，我们可以将这类成员B的特有性质再进行抽象
本人可能比较菜 发表下个人体会
面向对象是你对所要处理的事物使用的设计思维方式
多态、继承、封装都是为了达到面向对象这个目的所使用的方法或工具。
如果你设计的时候没用面向对象的思维去分析这个事物，就算你用的多态、继承、封装也不一定是面向对象的。
估计你的领导并不是错的，可能你的设计过程中的确还有很多可用面向对象代替面向过程的地方。
不过这是长时间经验积累慢慢形成的思维方式，久了你自己就董了。
你现在应该努力去寻找面向对象比面向过程优越的地方。 面向对象 呃···我越看越抽象了···
很简单的说·就是把一条数据变活·比如 一个养鸡场.....
里面有 鸡 ， 人 这个二个对象
每个对象呢
对象的属性：
鸡： 公母,重量，毛色；
人：名字,性别,身高,体重等等。
我来“渲染”下我这个养鸡场：
首先 建造养鸡场 笼子什么的··
有好多鸡 就是生产很多对象·哈哈 ： 鸡 小鸡 = new 鸡（）；
招聘很多人来养鸡： 人 R = new 人（）；
不知道这样说对不对哈·反正我就是这样看待对象的··..关键还是思想··
引用 25 楼 wanghui0380 的回复:
引用 22 楼 SkyIsland 的回复:
比方说我做一个工资管理系统，我要通过一些参数来计算出员工的最终工资。那么我就做一个工资类，然后在里面放一个通过各种参数来计算工资的方法，需要调用的时候就实例化工资类，然后调用这个工资计算方法，我肯定不会在Page_load中一行一行那样从上向下一直写下来。
也就是说，我采用的方法跟你采用的方法是一致的，你觉得那里有问题？
问题还是在于变化！
普通工人的工资
管理人员的工…
这个回答不错，说到重点、 我觉得核心就是面向抽象编程。
C# code InterFace IProduct { void DoSomething(); } Class ProductA:IProduct { public void DoSomething() { //代码 } } Class ProductB:IProduct { public void DoSomething() { //代码 } } IProduct A = new ProductA(); //不要用 ProductA A=new ProductA(); IProduct B= new ProductB(); //不要用 ProductB B=new ProductB(); private void DoSomething(IProduct product) //如果不是面向抽象，每种产品就要单独写这样一个方法了 { //而且以后还可以增加ProductC....，这个方法是不需要改的。 product.DoSomething(); }
只是一个简单的例子，请大家参考指正
非常同意 楼上。这也是我学设计模式总结出的一条。
抽象是固定的、不变的。我们程序中将来可能会发生改变的部分应面向接口编程，而不是面向具体的多变的对象，这样，当对象发生改变后原有程序的架构可以保持不变。 这可能是老手的新手的区别，项目做多了，知道什么地方需求经常改变，在设计时就留了后门，新手不知道，或者根本没考虑这方面，全用了对象，需求一变，不得不改。
引用 184 楼 davidxu1969 的回复:
我觉得核心就是面向抽象编程。
InterFace IProduct
{
void DoSomething();
}
Class ProductA:IProduct
{
public void DoSomething()
{
//代码
}
}
Class ProductB:IProduct
{
public void DoSomething()
{
//代码
}
}
IProduct A = new ProductA();
//不要用 ProductA A=new ProductA();
IProduct B= new ProductB();
//不要用 ProductB B=new ProductB();
private void DoSomething(IProduct product) //如果不是面向抽象，每种产品就要单独写这样一个方法了
{ //而且以后还可以增加ProductC....，这个方法是不需要改的。
product.DoSomething();
}
如果有一万种产品，那不是要写一万个Product类？阿里巴巴网站上不止一万种产品。 面向对象编程：先把一个问题抽象化出一个类来（类的属性--即数据成员--和方法---即成员函数）；面向对象的模块是“类”。面向对象的编程是以类的设计为基础的--即把待解决的问题抽象出一个类出来。
面向过程编程：把解决一个问题当作一个主函数--对应main problem(主问题)，把主问题分解成几个子问题，然后把要实现的一些细节问题（即子问题）当作主函数中调用的一些函数；面向过程的模块是“函数”。面向过程程序设计通常是采用自顶向下设计方法设计的---即将待解决的问题分成几个子问题。 这是我们一向从书本上学到的，但很多东西还是向大家说的那样，实际操作中问题是 五花八门！引用 194 楼 wyan117 的回复:
面向对象编程：先把一个问题抽象化出一个类来（类的属性--即数据成员--和方法---即成员函数）；面向对象的模块是“类”。面向对象的编程是以类的设计为基础的--即把待解决的问题抽象出一个类出来。
面向过程编程：把解决一个问题当作一个主函数--对应main problem(主问题)，把主问题分解成几个子问题，然后把要实现的一些细节问题（即子问题）当作主函数中调用的一些函数；面向过程的模块是“函数”。面向过程程序设计通常是…
引用 190 楼 SkyIsland 的回复:
引用 184 楼 davidxu1969 的回复:
我觉得核心就是面向抽象编程。
InterFace IProduct
{
void DoSomething();
}
Class ProductA:IProduct
{
public void DoSomething()
{
//代码
}
}
Class ProductB:IProduct
{
public void DoSomething()
{
//代码
}
}
IProduct A = new ProductA();
//不要用 ProductA A=new ProductA();
IProduct B= new…
如果有一万种产品，那不是要写一万个Product类？阿里巴巴网站上不止一万种产品。
阿里巴巴网站上的一万种产品是一万个对象,但它们同一类产品都是一个类(ProductA或ProductB)引申出来的.
184楼这段代码很好. 面向过程和面向对象：
-面向过程 概念的提出是人遇到计算机时怎样把问题交给计算机处理，让其一步步执行，最初的过程是让机器来解决人单以的繁琐事情。
-面向对象 概念的提出是计算机 网络飞速发展 以前面向过程的方法有其不完善之处，可以初略的说不哪么与时俱进了，在快速发展的今天，我们不再为解决单一的事情忙碌了，而是需要解决更加复杂的事情，对于我们自己需要解决什么问题，怎样去解决问题，把所有需要解决的问题放到一起考虑，那就有了各种各样的解决方法，把各种解决方法进行有目的的组合集成解决方案。面向对象的提示实际上就是为了解决人的问题而提出的。
面向过程是人的思想，面向对象也是人的思想，只是在不同阶段不同历史条件下提出的，一个有无到有，有初级到高级的过程。我们考虑问题时需要有面向对象的思想，因为我们需要解决人面临的问题，我们要实现，把这种实现交给机器去处理时，那就是面向过程，没有过程就要不到结果，就解决不聊事情。
不管哪个O我们要理解是其思想，具体实现中肯定是 你中有我 ，我中有你，没有面向过程就不成立面向对象。 这两天凑巧也在考虑这个问题，个人心得：
面向对象和面向对象都是一种抽象的方式，为什么面向过程首先应用于开发，而面向对象是后来的，追本溯源来说是开发人员对解决问题的方法的进化，面向过程是在计算机的角度思考问题的解决办法，是在计算机的解空间中实现的；而面向对象是在人类的自然思维中形成的，也许是因为面向过程对于解决非常大或需求变化频繁的问题上比较吃力，所以才出现了面向对象的方式；面向对象也是解决这两个问题为出发点：
1.抽象的难度要降低，符合人类的自然思维相对于面向计算机的角度更为自然，简单。
2.隔离变化，封装和多态目的就是隔离变化，把易变的和不变的分开，简化需求不断变化的应付成本。
个人感觉，高手不要见笑。 阴阳是私有对象
五行是逻辑
爻是函数
八卦是类
六十四卦是继承后的类
最后《周易》面向所有的对象，无论是哲学家还是大仙们都能得到自己想要的东西……
哈哈，恶搞一下 引用 68 楼 SkyIsland 的回复:
总结大家的发言：
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的方法要多实…
其实根据我做的项目的经验，我觉得，不要死死的盯在OO上，只要能灵活的掌握封装、继承、多态、interface（个人觉得interface应该是一个贯穿的“通道”）的应用以及一些简单的设计思路就可以了，不要把OO用死了，即使不是OO又如何？
对于需求的变更，我觉得可以在Class中“扩充”，但是需求是永远是无止境的，当然人的智慧也是无限的，用户永远是上帝，但上帝很少又讲理的时候，所以，如何看待需求，处理需求，就看你的项目经验和处理能力了。做项目一定要做好需求分析，跟客户钉死一些东西，不要搞乱自己的计划就可以了！
为什么会有面向对象这个东西，如果是一个人开发一个非常简单的系统，可以简单到只有一个方法：计算给定长宽的长方形的面积。那么有必要用面向对象来实现吗，如果改为计算给定半径的圆面积，哪么面向过程的方法可能修改起来更容易一些。
但是如果是很多人开发一个非常复杂的系统，每个人的流程交织在一起会形成一个网，这时如果不用面向对象的方式，那就等着崩溃吧。
还是用算长方形和圆来举例。如果是面向过程的开发，算长方形的函数改成算圆了，要通知所有曾调用算长方形的人修改代码，而且可能还有部分人就是要算长方形不算圆而不用改代码，那如果下次又修改了计算圆或长方形的函数，怎么通知；每个开发人员一修改自己的代码，就造成大量的其他人员也要做相应的修改，那还能继续开发下去吗。这里只是个极端的例子。
使用面向对象的方式，通过封装、继承、多态，接口等使修改限定在使用修改的地方，与其他人，其他代码无关。
以上是我对面向对象的一点粗浅认识，可能意思表达的不算准确，欢迎大家批评。 面向对象编程旨在将现实世界中的概念模拟到计算机程序当中
面向对象编程核心思想是对象，我也记不清在哪看的一句话说的不错，“一切皆为对象”
对象的定义就是存在的具体实体，具有明确的状态和行为，而类是具有相同属性和共同行为的一组对象的集合。
他们之间又本质上的区别，类是用来描述实体的“模板”或“原型”，而对象是实际的实体，每一个对象都是类的一个实例，所以通常“为类创建一个对象”也叫做“为类创建一个实例”
举个例子吧
又一个叫咪咪的小猫和一个叫笨笨的小狗，它们都是“对象：，但是它们属于动物，也是一个“类”。类是对象的”原型“，它为特定类型的对象指定了允许的操作和必要的特征。
我觉得不要把它们想的那么复杂，那样反而理解不了，实在不行就死记硬背吧，编程的时候慢慢就理解透彻了 引用 6 楼 SkyIsland 的回复:
人人都知道是一种思想，能具体的描述吗，面向对象的设计，面向对象的编码，如何设计？如何编码？数据表映射实体类不是面向对象，那怎样做才是面向对象？我真得很想知道！
也很想知道! 就该是用OO的方式把业务逻辑实现出来。。
比如在进销存中，采购入库、销售出库等收发业务都与收发记录表相关，
这就得写个收发业务的基类，在派生出各收发业务的类。
基类里实现共有的方法，在各子类中可以覆盖父类的方法，以实现自已的处理方式。
还是要 悟
面向对象的特点就是 多态，封装，继承，重用
但是，面向对象是一种哲学，是一种思考事物的方式，领悟了这种思考事物的方式，你会觉得面向对象的设计很简单
认识面向对象的过程和认识其他事物一样，从简单到复杂，再从复杂到简单。
说的没有错：悟 ；但是各有各的理解，能不能把各自悟到的写出来，让人看的明白，相互参详。
------------关注中-----------------------------------
呵呵 一百年前的马车，现在仍然有人坐……
现在的出租车也一样的跑……
你同时坐过马车……也坐过出租车……
如果每次你打出租车时，出租车司机非要你解释清楚“马车是怎样工作的？”，解释不清楚就不让打车……
那么你会怎么说？LZ问的问题就是现在的问题…… 其实面向对象最主要是哪个面向对象的过程，整个程序的设计和思路用面向对象化的方法来实现，
这样做出来的程序的结构就想一个社会一样，分工结合完成整个任务，
扩展整和就相当的便利了 引用 24 楼 yunfeng007 的回复:
引用 19 楼 SkyIsland 的回复:
引用 18 楼 TLJewel 的回复:
打个比方，让你编一个计算正方形的程序，一般的思路是：
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类
你这样的例子没用！比如说我做一个网站，而这个网站里有个计算正方形面积的功能，我完全可以像你说的用一个Square类来表示正方形…
精典。跟我的想法一样 引用 68 楼 SkyIsland 的回复:
总结大家的发言：
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的方法要多实…
我理解面向对象开发思想是为复用而生的.
大处着眼,小处入手.
客户需求多不要紧,从最小处入手,做成构件(只有对象的思路才好实现),按需供给.
好象还是有点虚.
不用太大,有个实例就好说明了. 你可以这样对你经理说:我现在面对你,那我就是面向对象.如果他要是还认为你是不对的!那只能说明他是个类! 大家说说用一个简单的面向对象开发的过程是什么？
用Duwamish作例子吧。按如下顺序：
1、需求分析
2、全局分析
3、局部分析
4、全局设计
5、局部设计
6、细节设计
最后得出的系统架构是怎样的？
我觉得，设计模式应用在局部设计和细节设计时期。
看看这段：
public class You
{
public void DoThis(){}
public void DoThat(){}
public void ...
}
You被实例化了，You要DoThis，DoThat,Do...,因此，You是面向过程的。
public class YourManager
{
public DoAll()
{
在此实例化了You和一些和You类似的对象，然后调用这些对象的“面向过程”的方法。
}
}
所以，我们可以看到，YourManager是面向对象的，You不是。 就是用计算机语言模拟现实世界中的对象 我觉得OO有点像组装车间和拆解车间.
比如说:
主机+显示器+键盘+...=电脑
一个电脑+一张电脑桌+..=办公位置
两个电脑+两张电脑桌+人+..=办公室
如果我们要建个办公室,那么我们就按照办公室的要求自上而下的找齐各种东西就行了
面向对象编程时,设计时,一般我们都是先到拆解车间,把需要的东西都列出来.
编码时,就到生产车间,把一件件小零件做出来,再到组装车间把零件组装起来.
基于过程的编程,往往是为了做一个办公位置,而做一个办公位置,为了做一个办公室而做一个办公室.这样子办公位置跟办公室一点关系都没有.
而面向对象编程,可以根据现在的办公位置,任意的组装成一个办公室了.
我想这就是过程与对象的区别吧.
很多人认为多层结构就是对象.其实这是错的.
多层结构本应该是为了实现对象的联系,而设计的自上而下或自下而上的实现.但是很多人,在使用多层结构时,往往是对数据库的需求分解,而不是对业务实际对象的分解.
其实，编程就向是什么做翻译，把人的思想翻译成计算机能运行的东西，
而编程的方法在有一个思维趋势的情况下变化，这个思维趋势就是附合人的思维方式，
这里说的人不是以前学过编程的人，而是刚明白事儿的小孩，因为他们不知道想完成一件事到底应该怎么一步步的做，
比如上一个房顶，他们想的是自己能飞，一下子就上去了，
而我们想的是先找个梯子，搭在房子上．．．．
这就是面向过程和面向对象的不同．
其实面向过程和面向对象一点都不矛盾，
类中的方法还是要一步步的写，
再比如一个飞机是一个类，
我们是做飞机的人，我们在做的时候还是要一步步做，当有人按下什么时有什么样的反映，
小孩是坐飞机的人，他不知道为什么飞机能飞，只知道按下什么有什么样的反映，
自己编程只是把小孩的角色也充当了
确实 大家都说的狠好 我是个新手 现在在学习C# 关于面对对象的事情特别头疼 但是 今天听各位大侠的高谈阔论 我总结勒几点
面对对象就是:
1.主要就是继承,首先要先把基类定义好,留下可变空间
2.其实面对对象,就是一个消除重复,精简代码的过程
3.用面对对象来应对客户的变化,
本人是新手,看到你们的思想狠有感触,以上写的,只是个人见解`` 上面很多人说的都是OOP的思想,也就是面向对像的编程,也是学校里学的比较多的,出来了多做苦工,
而面向对像大体分为三层,而且在社会上也会因你撑握的层次决定了你的价值,
像多态,继承等,其实都是比较浅的,当然是相对于面向对像这个知识体系的.
面向对像大体分为OOP,OOA,OOD分就是面向对像编程,面向对像分析,面向对像设计
而后面二个才是面向对像的精髓,像架构师级别的人就一般做的后面二种工作
个人理解吧, 引用 272 楼 Magicwords 的回复:
上面很多人说的都是OOP的思想,也就是面向对像的编程,也是学校里学的比较多的,出来了多做苦工,
而面向对像大体分为三层,而且在社会上也会因你撑握的层次决定了你的价值,
像多态,继承等,其实都是比较浅的,当然是相对于面向对像这个知识体系的.
面向对像大体分为OOP,OOA,OOD分就是面向对像编程,面向对像分析,面向对像设计
而后面二个才是面向对像的精髓,像架构师级别的人就一般做的后面二种工作
个人理解吧,
看了两晚一头雾水，看到这个更晕 长期关注这个帖子 希望有个牛人可以总结一下什么是面向对象 看概念大家都是那种似懂非懂的地步
知道有这么个概念也知道有一些什么样的方法 可是运用的时候却出现LZ说的那样 回到了面向过程
所以有个具体点的实例来讲解是最好不过的了 毕竟概念的东西每个人的理解都会随着他的水平而有所不同 面向对象的难处不在于构建对象,而在于要构建那些对象,对象之间如何相互协助工作.当你面对一个程序时,第一时间想到的是,我要处理的事务中涉及了多少个对象时,你就理解面对对象的真正概念了. 引用 155 楼 NeuMik 的回复:
面向对象 呃···我越看越抽象了···
很简单的说·就是把一条数据变活·比如 一个养鸡场.....
里面有 鸡 ， 人 这个二个对象
每个对象呢
对象的属性：
鸡： 公母,重量，毛色；
人：名字,性别,身高,体重等等。
我来“渲染”下我这个养鸡场：
首先 建造养鸡场 笼子什么的··
有好多鸡 就是生产很多对象·哈哈 ： 鸡 小鸡 = new 鸡（）；
招聘很多人来养鸡： 人 R = new 人（）；
不知道这…
是这个样子！ 引用 272 楼 Magicwords 的回复:
上面很多人说的都是OOP的思想,也就是面向对像的编程,也是学校里学的比较多的,出来了多做苦工,
而面向对像大体分为三层,而且在社会上也会因你撑握的层次决定了你的价值,
像多态,继承等,其实都是比较浅的,当然是相对于面向对像这个知识体系的.
面向对像大体分为OOP,OOA,OOD分就是面向对像编程,面向对像分析,面向对像设计
而后面二个才是面向对像的精髓,像架构师级别的人就一般做的后面二种工作
个人理解吧,
看了好多天觉得有点自己的想法了，说来给大家分享一下
对象 我理解的就是 类的实例
如何面向对象呢。
就是把这个对象放到需要这个对象的地方
例如单位招人 需要 1个 计算机专业 能做C#的人
只需要招到1个 计算机专业毕业，能做C#的人就可以了，并不在乎这个人是谁。面向结构的就必须知道这个认识谁
这样，这个人完成这份工作后，并不代表他就“废了”，他还可以继续到需要同样人才的单位去完成工作。
代码的利用率就很高了。
面向对象和面向过程 是没有完整的界限的。
所有的对象里面，都是有一些数据，和过程组合出来的。
而且有时候，纯粹对所有东西进行对象化，反而影响性能和开发效率。
怎么使用就只有看自己的规划或者看项目经理他们是怎么规划的。
是用
对象.过程()
还是
过程（对象）
就只有具体问题具体分析了。 建议你去学学设计模式的课程，在经典的23种设计模式中，除了单例模式其他模式都涉及到了封装，多态和继承，当你学完以后，肯定会对面向对象设计思想有一个新认识 这帖不错.
个人认为,楼主搞不清楚的地方是:为什么我用"对象.方法()"来写程序仍然被人指为面向过程式的编程.大家说了一大气,都没有讲清楚讲具体,所以就算楼主把回帖全看了,也还是没办法理解.
在下在这里简单又粗糙地向楼主解说一下,如果有错,也请大家指正:
如果在你写的主程序的主要执行代码里是以下这种情况:
...
对象1.方法1();[这里调用如此多的方法是为了得到返回值后,让其他计算步骤再利用]
对象2.方法1();
对象1.方法2();
对象1.方法3();
对象2.方法2();
...
那只能说,你把不同对象的不同方法有效地结合到了一起,你的方法起到的不过是个计算式的某一步的作用,相当于一大堆的计算代码行.这样看,你的思维仍然是行编程的.只不过把很多行简化成了某个对象的某个方法.
如果在你写的主程序的主要执行代码里是以下这种情况:
对象1.方法1();[只有对象创建和简略的几个对象方法的调用,基本不返回值,也不需要提供什么返回值给其他的计算来利用]
那这基本上就算是面向对象的编程了.为什么?因为你将大把的计算处理,全都抽象整理到了创建对象的那个类中,这里面有关于这个类的对象的全部方法,与其他类的关联达到最弱(弱藕合).这样它的再利用的价值就会达到最高(可重用).而且可以证明你的业务已经被提取到了这个类的内部(抽象,封装).
*当你对上述两段代码进行修改的时候,你就会发现明显的不同.
第一段代码,你需要在主程序中不断地修改每个对象的每个方法,因为业务变了,步骤也就都变了.
第二段代码,你根本不需要在主程序中修改什么.你只需要修改创建对象的那个类的某个方法.因为业务再变,也只是某个抽象后的对象的处理变化了.
其他的区别就不一一列举了,你弄清楚这些,就差不多算是知道两者之间的区别了. 经典的话题.....
看了一半,没心思看下去了.
个人认为 不管是面向过程,还是面向对象,只是一种设计思路而已.不是面向对象比面向过程更先进,那现在的CPU有面向对象执行的吗?
所以在该用面向对象的地方用面向对象,该用面向过程的地方用面向过程的设计思路.
面向对象在对代码的可重用性、框架设计的接口统一性、代码的可维护性方面有很大的优势，而在做系统时，面向过程的设计思想我想是不可能完全被遗弃的，因为一个具体问题的解决，还是过程化的。所以我认为应该是两种设计思路想结合的方式，不要走向任何一个极端才是正途。
呵呵，一个菜鸟，说得不好，请高手专家指正。 楼主你说的那个是面向过程吧。。面向对象就是高级编程。。。就是把需求看成对象。。实在的东西。。 引用 24 楼 yunfeng007 的回复:
引用 19 楼 SkyIsland 的回复:
引用 18 楼 TLJewel 的回复:
打个比方，让你编一个计算正方形的程序，一般的思路是：
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类
你这样的例子没用！比如说我做一个网站，而这个网站里有个计算正方形面积的功能，我完全可以像你说的用一个Square类来表示正方形…
你说的不对．．．即然使用了反射．还有必要改变以前的代码吗．答案是不需要的．．可以新建一个dll文件实现写入文件的操作．利用反射修改config文件不就可以了． 如果完全采用面向对象的设计去开发产品，那么开发出来的产品肯定是一个艺术品，艺术品就是用来看的，没有使用价值。起码在目前的面向关系型数据库的基础上，要考虑性能的情况下这样做是不可能的！ 培养OO思想其实很简单，当你遇到一个需求时，先把这个需求拿出来，单独思考，想他可能有什么属性，有什么方法，是否有功能类似的兄弟姐妹，之后单独实现，并且用单元测试来测试。 最后在回到需求点调用。
借用24楼兄弟的例子，如果你现在写UI，需要记录log，你可能很自然的想到
class Logger
{
void Log(string message){}
}
然后你回到UI，调用Logger.Log("用户登录成功了")，这就是典型的面向过程的思想。你甚至可能会写个Logger的接口，但你的思想还是面向过程。
而如果你想我的项目需要一个Log功能，他可能需要记录exception，记录Event，记录自定义的Message，他可能记录到database，记录到文件，甚至记录到串口，或许将来会记录到不可预见性的地方，那么你需要提供配置文件，Logger工厂和继承的子Logger来扩展。 这样，一个丰富的，有血有肉的Logger对象浮出水面。
接下来你可能考虑如何调用这个Logger，直接在UI调用可能是不明智的，他违背了MVC原则，那么你可能需要一个SystemEvents对象，专门负责抛出各种各样的Events，或者打入MessageQueue。好了，既然我们有了SystemEvents对象，我们还需要一个监视对象来监视SystemEvents的变化，并最终记录到Logger中。
OK，小功告成，我们有了一套互相协调工作的对象，大家互相配合完成一些工作，这时候你可以完成你的代码了，你的代码可以写的非常丑陋，你可以没有继承，没有多态，但是你的思想已经是OO思想了。
很多朋友可能误解了，以为继承，多态就是OO。其实OO在前，技术在后。先辈们有了OO的思想，然后发明了继承，多态等技术来更好的实现这种OO思想。记住，OO是思想，是思路。
面向对象编程应记住以下三条原则
① 针对接口进行编程，而不要针对实现编程。
② 优先使用对象组合，而不是类继承。
③ 封装变化点。
再明确一下开闭原则：
面向扩展开放，面向修改封闭。
你们项目经理把过程和流程搞混淆了吧
比如你做网页，这网页就是个Page对象，你在Page添加若干个text，然后对其进行操作，获取数据，提交至数据库，记录数据。这个流程中的每一步都会用到面向对象的编程思想，但整个实现方面是面向流程的。不能说这个就是面向过程了。 太多了,实是难得看完,说说我的观点.
其实关于面向对象,我的总体看法是把事情简单化,而不是追求什么所谓分层,多态.继承等,那些只是实现面向对象的方法而已
面向对象,说大点就是封装,说小点就简单化操作,也可以说是偷懒的一种手段,当然,有时候也不见得能偷懒,这个得看你把握全局的能力了
说个简单的比方,比如用户,他拥有一些常规属性,所谓面向过程或者其它编程方式就是按用户的相关属性,然后针对每一个属性去操作,这种写法很直接,也最能容易理解,但我们实际操作中发现,用户的属性偶然会发生一些变化.或者会添加一些特殊属性或者删除某些属性,如果是面向过程,那么这个时候你要修改就麻烦了,也就是我们常说的维护困难.当系统非常宠大的时候,这种修改代价往往相当于重新开发,甚至...,所以我们要应用面向对象,操作的时候只针对用户,而不管其属性,它的属性则用其它相关子类或者其它方式来处理,也就是我们常用的实体,当然,为了实现这些操作,我们就会应用继承,多态等等.这些一组织起来就是封装.所以这个时候如果用户属性发生变化.那么就只用修改实体就行了,而不用或者很少修改别的地方...从而提高系统的可维护性与扩展性.
以上仅仅我的个人理解,词语并不专业,觉得讲通俗一些比较好.希望大家指正 引用 19 楼 SkyIsland 的回复:
引用 18 楼 TLJewel 的回复:
打个比方，让你编一个计算正方形的程序，一般的思路是：
定义3个变量，a=长，b=宽，c=a*b
而面向对象的思路：
先创建一个长方形的类，在类里定义两个属性分别为长、宽，再定义一个面积方法
然后实例化这个类
你这样的例子没用！比如说我做一个网站，而这个网站里有个计算正方形面积的功能，我完全可以像你说的用一个Square类来表示正方形，长、宽是属性，计算面积是方法，然后…
对呀，你这样看当然还是老样子了，但是如果你还计算别的东西呢，如周长什么的，就可以再实现一个方法就可以了。
如果你又要计算别的图形呢了？ 就可以继承了这个正方形了呀。
换一个说法，先定义了一个抽象类，里面有属性 边长，有虚方法 计算面积、计算周长等等。
以后你的图形类就可以继承自这个抽象类了。 呵呵我也说说我的看法.
我接触面向对象也有半年时间了.写简历的时候写上了"对OO思想有比较深刻的理解".结果去面试一下就被人问住了.
我以为面向对象就是抽象,继承,封装,多态的实现而已.与OO思想完全不搭边...
有句经典的话是这样说的"现在的人都打着面向对象的幌子,做着面向过程的勾当"...想想也确实这样啊,我做程序从来没想过面向对象.总是专著于事情解决的步骤.以前用VC写了个俄罗斯方块.完全没有任何面向对象的感觉.后来学习JAVA的MVC,SSH啦.丝毫没有感觉到什么是面向对象.真的是那句经典话说的那样啊..
题西林壁
横看成岭侧成峰，远近高低各不同。
不识庐山真面目，只缘身在此山中。
OOP.OOA.OOD.
OOP专注的是什么?OOP专注于接口的复用,接口的组合.来解决更实际,更复杂的问题.不是让你凭空的发明创造,而是多多利用现有的类,组合出更实际的类,更实用的类.想想现实世界中的一款款新型的汽车,他们都不是面向过程的方法设计出来的,他们都是面向对象的结果啊.需求驱动,接口复用啊.现写这么多.
引用 2 楼 virusplayer 的回复:
面向对象不是流程，而是一种看待事物的方式方法，是一种思想，一种思路，其实他们也不见得搞得清楚，时间长了你就有自己的理解了，他们说对，让他们坚持吧，项目还是要继续的
记住：面向对象只有三个最基本的特征：1、封装；2、继承；3、多态。无论怎样，便被二者的时候时刻牢牢核对此三者，时间长了你自然能体会，那种境界是只可意会不可言传的。 个人觉得这个问题很深奥，需要慢慢体会。
面相对象是一种思想，一种解决问题的思考方式，而面相过程侧重于具体的项目解决方案。我想没有人敢说自己的方案完全是面向对象的吧，它们之间是一种相互交织的关系，你中有我，我中有你。
个人见解，见笑了。 我是一名初学者，我的见解是：面向对象考虑的是谁去做，面向过程考虑的是怎么做，也就是说使用一个类时就是面向对象；在建一个类时就是面向过程，好比你要寄一份信你考虑的是让邮局去寄不需要知道邮局是怎么把信送给收信人的这就是面向对象，当你建邮局这个类时就必须要考虑邮局是怎样把这份信送给收信人这就是面向过程 很不错的贴啊，大家好好学习哦，呵呵，我也会加油的 忍不住要说两句：
有没有人思考过你们讨论的面向对象这个概念的应用范围（或者也可以说应用域）？需要实现OO的范围是什么？
OO的范围可以无限细化下去，也可以无限放大。
OO细化
应用你们之前说的例子：计算正方形的Square类，如果再细化下去，对Square的面积方法内部的过程也同样还可以OO化。
通常的写法：
//==============================
void Square.Acreage(){
return this.width * this.height;
}
//=================================
把Acreage()过程再OO化的写法：
//====================
class OperationMultiply{
public static object Do(int width, int height){
...
return result;
}
}
void Square.Acreage(){
return OperationMultiply.Do(this.width, this.height);
}
//=======================================================
....
按照这种细化方式可以将代码无限的OO下去（大家当然会说这样有必要吗？？）。甚至OO到汇编层次。。。那肯定是超牛人才做得到的！
OO放大
OO放大的例子就太多了，Page类，Form类。。。再放大正如你们之前提到的PetShop，甚至DataLayer都可以看成一个对象来处理。。。再放大整个Project的Application也是一个类。
由此可见，OO的概念可以向两极无限的延伸，关键在于你自己的代码中如何来定义这些Object的。定义的好，就能给整个项目带来很大的灵活性。定义不好，那就是所谓的面向过程咯。
至于设计模式，继承。。。等等，只是实现OO的方法。[color=#FF6600]关键在于如何定义你的Objects!![/color] 面向对象嘛，怎么说呢？随便一本C++书上面都应该讲过面向对象的思想，你仔细思考一下C++上面的那些代码为什么要那样写。有些代码可以直接写成面向过程的，而且效率还高一些，为什么要写成类呢？这不是浪费时间吗？你把这些问题想清楚了，那你就明白什么是面向对象了，以及为什么要面向对象。 明白了过程编程和对象编程的思想和实现方法之后,对于C#程序设计的学习,也在采用对象的思想方式和组织方式.将它们分为了界面,存储信息,方法,事件,类型等对象来进行学习.事实感受这样是很有效的.想通过需要来学习程序设计.上午的时候，想到学习程序设计，造成了日常状态的表现差劲，因而，想采用对象的方法，对日常生活的基本管理进行一些封装，做成一个类，来进行调用。同时以此例来探讨程序设计的学习。
//在学习程序设计的时候，调用日常管理。
using 人生system；
namespace 个人管理
{
class 日常
{
private string 安全；
private string 睡眠；
private string 健康；
private string 营养；
private string 卫生；
private string 穿衣；
}
~ 日常；
}
附 面向过程或结构的理解:如汉语拼音,英语的26个字母,英标等,象这类成熟定型地内容,易采用过程和结构的方式,做成了结构后,此时结构成为了一个整体,同时也成为了一种对象."固定能产生智慧",过程和结构编程,易出境界.对于不确定的内容较多和需扩展的内容,宜采用与面向对象编程的思想和组织方式.明白了它们的精义后,两者可任意选用和相互调用.
附 面向对象的理解.比如说,学习C#,一直从头学到尾,不停地学,这样总体上就呈现的是过程的思想和行为.而如果把它分成几部分,如信息存储,方法,类型,事件,界面等,每学一个主题,设定好效果,完成任务后,即完成了一个对象,随时可以停止,重新开始时,某些达到要求的对象,可以不用再学,或者稍做复习.而以整体做对象则每次开头,都要重新从头开始. 我觉得所谓面向对象，面向过程。你不应该用代码去考虑，而是从整体的架构上去理解。面向对象就像是搭积木，你要完成一个任务，比如说建一个楼，我就找够这么多块砖，以块一块地搭起来，以达到最终完成我们的任务
（建楼）的目的。而面向过程则是按照先打地基，然后从下到上一步步建这样。我认为面向对象就是可分解的，
他可以单独地拿一部分出来还有它的意义，这是一种概念上的东西。
又说面向对象在实际开发中的意义，是为拉应对多变的快速的大规模开发，我们可以想象，人数越多，影响项目
速度的不会是代码的数量，实际上是多人的配合性，那么如何让多人配合得更好，尽量减少重复开发，解决这个
问题用面向对象就很容易理解。把一个项目（大对象）拆分成各个功能模块(小对象)，在各开发人员中，我只需要
通知你需要连接的接口，而你不需要去了解另外的开发人员是如果实现那个接口的。每个开发人员只需要关注自己
要实现的功能。
面向对象和面向过程差别就在于你看待事物的着眼点上，既事物是否可以分解，分解出来的事物是否有它的独立
完整性。
打个比方，用面向过程的观点去看一个人，这个人是用血液来连接全体，你造个人是先用从脚开始往上造，但是
面向对象呢，则是把一个人看成是各种器官组合而成的，我们每个人造个器官，造好啦直接拿过来组装成就完啦，
从这点来说，人越多，就可以把一个人分成更多的器官零件来分发，那么造人的过程就越快。
而从对象来说，它分为两个部分，属性和方法，既我们的项目拆分为多个对象，而每个对象统一的由属性和方法构成。我们只需要这个部分有什么作用，而无需去了解它是怎么实现的，这就好比电脑的USB接口，谁都知道他可以读U盘，而我们只要把各种实现啦这个接口的如U盘往上一接就可以拉。换而言之，构造出来的对象，你可以随便拿给任何一个人来用，而要做的只是IMPLETER OBJECT而已。 引用 104 楼 zhenghaibingood 的回复:
目前只能理解到：
如果说话不方便，那么首先，
把名词看成名词，把动词看成名词，把形容词看成名词……（封装）
一切都成为名词后，
把a名词和b名词[c名词……]看成同一个词（抽象）
一切都成为好用的基本词汇后，
在相近的场合跟人家说基本词汇，听者自己会理解这个基本词汇表达的意思（多态）
如果比较懒或场合需要，利用基本词汇组合成能很好地表达意思的新词用用（继承）
很傻的理解，见笑了。
有点意思的见解。应用上的确如此 一个程序中有很多
对象1.方法1()
对象2.方法1()
对象1.方法3()
....
单从这个程序上来看并不能说明是面向过程还是面向对象
必须得从一个更高的,全局的角度来看待整个问题 才能判断你是否真正的用到了面向对象的思想,或者只是打着面向对象(class)的幌子在搞面向过程 我的理解：
一个商场有很多的营业员，营业员分好多种：卖手机的，卖菜的，卖水果的
那么这个时候我就想定义一个基类
public class 营业员，
然后就把卖手机的，卖菜的，卖水果的都继承营业员，
如果哪天商场里面又新来了些卖衣服的
我们不需要再去重构，只需要把卖衣服的营业员继承营业员，加入卖衣服的这个特性
以此类推，卖手机里面又分为卖NOKIA，MOTO的，那么就再继承卖手机的营业员
也就是说：设计程序的时候，要找到业务流程中各个对象已存在的最基本的相同的地方，然后设计一个基类，即使需求再变，只要这些最基本的相同的地方没有变，你就可以继承这个基类——也就是说，当需求变化的时候，你不用再把这些最基本的相同的东东重写或者更改
个人认为：业务流程越熟悉，软件测试理论越熟悉，然后把握一个原则————那就是 我要偷懒！~ 就像追女仔一样,不同的人不同的做法,但大致两种:
一,以自己为主导,直接就行动了,直到追到对方为止,
评价:想法很少,成功率高,但结果不长
二,先考察对象,深入分析,结合周边的环境,最后是实际行动
评价:处心积虑,折磨死人,但能天长地久 举个例子：一台收音机作为一个参数传递进来，我们去打开收音机，调节收音机的音量，这就属于面向过程，而面向对象就是收音机本身给我们提供了一个打开它的方法和调节它的声音大小的方法，让我们去调用这些方法，利用这些方法来听收音机。。。。。。。。。 打个比方，你拦下一辆出租车，你告诉驾驶员，你要去某个地方，然后你就等司机把你送到某个地方就行了
这个过程中，你只需要知道有一辆出租车，里面有一个司机，
至于出租车是什么型号的，什么公司造的，生产日期，最后检修日期，
还有驾驶员是男的还是女的，叫什么名字，那一年出生的，生日是哪一天，什么时候开始开出租车的，
以及这次开什么路线，路上遇到多少个红灯多少个绿灯，
这些你都不需要关心。
你只需要
public void GotoSomeWhere(ITaxi taxi, Address address)
{
if (taxi == null && taxi.Driver == null)
throw new Exception("没有出租车或没有驾驶员");
taxi.Driver.SendTo(this, address); // （出租车）驾驶员送我到XXX地点
} 面向对象不仅是一种思想，
而且是一种成熟的系统分析和设计的技术！
“我做的东西是完全按照微软的一些权威的例子做的，比如PetShop、Dowamishi、强类型、泛型集合、DBHelper.cs、UserInfo、BLL.User等等之类的概念，但是经理说这些东西都是面向过程的方法。 ”
经理明显是忽悠你，微软发展到现在，面向对象已经是最基本的理念。
心里欢喜，看什么都顺眼。道理也一样，理解透了面向对象，就不会拘泥于个别的细节上。 面向对象没有最好只有次优就像下棋预见越高设计越好。主要在于揣摩客户的想法提前作出决断。所以要用依赖倒置原则。
尽量自然就对一般的设计来说就是成功。
我也是一个菜鸟。这些是学软件是我们老师教的，想请各位高手指教！！谢谢。 由第一楼看完，收获颇丰，所以忍不住回帖支持一下，希望讨论继续下去，希望可以有更多具体的例子分析。（刷新了两次才可以回复--！！） 我觉得不面向对象无庸质疑的包含了面向过程(流程)
面向对象可以提高代码的复用,增加灵活性,从而适应需要求变化
(依赖倒置),面向接口的设计.
它们之间是包含与被包含的关系,面向对象是一种成熟的软件开发(或设计)思想. 顶
---------------------
你的回复太短了！ 可能每个人对OO的理解都不同。我说说我的看法：
从C++的角度看，OO的核心思想有3：
1.多态 polymophism
2.继承 inheritance
3.封装 encapsulation
我个人对OO最白话的理解就是：每一个对象要做到‘自己的事情自己干’
如果全部在对象外部操作对象的属性，就成了伪OO了 :)
好复杂啊！我找个自己的“对象”也就3天时间，估计理解这里的对象3年都不一定搞得定！！！ 引用 350 楼 birdWing 的回复:
我觉得所谓面向对象，面向过程。你不应该用代码去考虑，而是从整体的架构上去理解。面向对象就像是搭积木，你要完成一个任务，比如说建一个楼，我就找够这么多块砖，以块一块地搭起来，以达到最终完成我们的任务
（建楼）的目的。而面向过程则是按照先打地基，然后从下到上一步步建这样。我认为面向对象就是可分解的，
他可以单独地拿一部分出来还有它的意义，这是一种概念上的东西。
又说面向对象在实际开发中的意义，是为…
说两句：
1、面向对像和面向过程有时候是相对而言的，对象中是以过程来实现的，而过程中又调用了基础对象，如：我们所引用的基类、控件等
本身就是一个对象。
2 面向对象的编程是从整体的角度出发，先把一些可能用到的公共类或模块等先建立起来,也就是再构建适合于项目需求的类，
后根据需要进行调用；如button控件，我先定义了项目所需的"确定“、取消、保存等用户控件，而后再使用。
举个类似这位老兄的例子，比如房地产商使用的模型，是先把各种可能的模块（如：房顶、外型、结构、绿化等等）先做好，
想要怎样的设计，就找基础模块搭起来就行了。
3 面向过程呢，虽然也使用了对象，也做了一些基础类等，但整体上是按步就班的处理事务，进行到哪做到哪，如上面举的例子：把button拉出来，再把属性改一改，一个项目下来，输了n次“确定”。
以上是个人理解，请高手指正。
编程都是面向过程的，而程序的设计才是面向对象。为什么要有架构师？架构师可能什么语言都不会，也可能什么语言都知道一点，你要他写个hellworld他还不一定写得好，但他的职责就是设计，就像楼上说的搭房子一样，架构师就像画图纸的一样，一栋高楼大厦，不同的人住在里面会有不同的需求，那就面临改建的问题，难道为了一家住户把整个楼拆了？当然不可能，所以在设计的时候就要考虑将来可能会面临什么样的改建需求，于是主梁应该有几根、地基应该打多深、改建时哪些地方会造成重心变化都要考虑。
继承、封闭、多态的确都是面向对象编程中提到的东西，这些是面向对象的核心，但个人认为：这些核心的核心都是为了一个词——重用。就是说为了减少编程过程中重复写大量相同的代码而提出的一些办法。
就拿前面举过的计算矩形面积的方法来说，这个方法只能计算矩形的面积吗？显然不是，假设方法为S(x,y)，方法返回的是x、y的乘积，那如果这样调用呢——S(S(x,y),z)，显然可以返回一个体积（可能是立方体也可能是圆柱体甚至是锥体），所以如果这个类里只有这个方法的话，那此类可在需要返回任何计算过程为两个数的乘积的程序中调用。
再拿这个类来举例，如果一个程序是计算面积的，第一天只说要计算矩形面积，于是你在程序中写(假设那个类名为A)
A a = new A();
double s = a.S(x,y);
第二天需求变了，添加计算x的y次幂的功能。于是你可能会在类A中添加一个方法B(x,y)返回x的y次幂，也可能你想到类的单一职责，再写一个类B，添加方法S(x,y)返回x的y次幂，但不管哪种你都得在主程序中再修改成这样：
double s = 0;
if(要求==计算矩形面积){
A a = new A();
s = a.S(x,y);
}else if(要求==计算x的y次幂){
A a = new A();
s = a.B(x,y);(或者 B b = new B();s = b.S(x,y);)
}
新的需求越来越多，但无论需求怎么变都是让你对两个参数作不同的运算。但你要改的还是会越来越多，主程序要添加的代码也越来越多。其实仔细比较判断中的两段，就会发现代码基本是一样的，只是调用的类的方法（或类）不同而已，方法的签名都一样！那怎样使重复代码减少呢？
利用反射即可漂亮的解决这个问题，写一个接口ITest，里面有个方法double T(x,y)；于是在主程序中你只需写这样一段：
String className = "";
/*不同需求就对className赋不同的值，值为对应功能的类的名字，最好把对应关系写在XML文件中，比如这样：
<GetName demand="计算矩形面积" ClassName="A">(这个只是图简单举的例子，具体怎样对应看个人爱好，呵呵)
这样以后添加新类的时候只需修改XML文件即可，而程序中只需用一个方法根据传入的需求参数返回对应的类名*/
ITest t = (ITest)Activator.CreateInstance(Type.GetType(className));
double s = t.T(x,y);
这样完成后，新需求来了，加个类，改一下XML文件，其他都不用动，而原来的类还能用在其他地方。这样很大程序减少了冗余代码，也一定程序达到了重用的目的。这应该算是面向对象的一个小例子吧。
哎，想我一菜鸟，不明白怎么个对象法，不过我在生活中的理解是：
比方说，早上你从家里出门去公司，从你家到公司是一个过程，而在这个过程中，你在路上会碰到一个个人，这些旧像对象，这些组成了一个过程，再在你碰到的对象里面又会有一个过程，就像你站那看一个美女走过，这样一个过程
引用 8 楼 kotiry 的回复:
面向对象 就是 在项目中的
封装,多态,继承 那些玩意嘛~
你的思想是过程的，所以他们说你没有理解这个玩意吗~
你用箭头表示你的思想 就是过程了~~~
说得有道理啊
面向对象就是 “偷懒”，理所当然的“偷懒”，
因为这种偷懒，才能使你们的软件在市场有竞争力，能随时面对需求的变化，最大限度的降低公司成本，
也是让自己的体力以及脑力价值最大化的方式
是聪明人的游戏！！
从技术层面来说，面向对象是一种经验，在前人的经验中，总结出来了很多种模式
模式是什么，是固定的玩意，是一种解决方案，
在思考问题的时候，发现问题，就可以开始套用模式了，
让自己在需求发生变化的时候，不至于累得要死，还只是拿同样的工资，
世界上最痛苦的事莫过于，发现自己累得要死以后，出现相同的问题，还必须用累得要死的方法解决，
然后又来了同样的问题，‘抓狂’，项目直接宣告失败，成本太高..老板开公司不是出钱为了让你重复”累得要死的方法的“！
对象就是一个很抽象很灵活的东西，它可以应对此方面所有的东西
面向过程：比如你做的一个程序，对你这个例子可以用，但是对其他类似的例子就要重写，而面向对象就是，只要加几个自己的类或者别的就可以继续使用，而不是从头再来。 引用 22 楼 SkyIsland 的回复:
比方说我做一个工资管理系统，我要通过一些参数来计算出员工的最终工资。那么我就做一个工资类，然后在里面放一个通过各种参数来计算工资的方法，需要调用的时候就实例化工资类，然后调用这个工资计算方法，我肯定不会在Page_load中一行一行那样从上向下一直写下来。
也就是说，我采用的方法跟你采用的方法是一致的，你觉得那里有问题？
工资管理系统，不一定要做工资类了。 可以设计 员工类阿，员工有各种属性：比如说工龄，出勤，职务，；还有各种方法：计算工资，计算奖金 等等。
属性和方法都可以在以后根据需要不断扩展，而且在扩展的同时，原有代码不需要修改。
你说的方法是伪面向对象。 这么热闹啊，不得不留下几个字了
其实在coding的过程里，任何经验都是渺小的，严重建议学习一下设计模式。
只有极近于完美的设计模式才极有可能让你最大程度面向对象，否则你都是在走到达目标的“面向过程” 大家的字为什么都那么小呢？看着真费眼啊。
大家都说得很玄，不是很懂，但感觉都没说到点子上。
我觉得：面向过程和面向对象是一个人称差别。
面向过程是第一人称，人称是“我”，这个“我”就是主程序流程，按照“我”的意图去调用函数。
面向对象是第三人称，人称是“他”，这个“他”就是各个对象，“他”可以只有一个，也可以有好多个，每个“他”都有自己的意图和流程，都在按照自己的意图办事。
真是强，估计是CSDN里最长的帖子。你这个问题
一个《大话设计模式》 可以讲得非常透彻 当开发游戏时就很能感觉到对象...那对象是实实在在的....
做企业软件开发，虽然类很多,但这些类要么就是数据的容器，要么就是方法的集合，又或者啥也没有。
在计算机语言中，这些东东实例化后仍可称得上对象, 但这与人们常识中的对象有很大不同 引用 22 楼 SkyIsland 的回复:
比方说我做一个工资管理系统，我要通过一些参数来计算出员工的最终工资。那么我就做一个工资类，然后在里面放一个通过各种参数来计算工资的方法，需要调用的时候就实例化工资类，然后调用这个工资计算方法，我肯定不会在Page_load中一行一行那样从上向下一直写下来。
也就是说，我采用的方法跟你采用的方法是一致的，你觉得那里有问题？
对于你来说，“工资”只是一个整数而已，而不是一个封装了属性和方法并且可以被多态使用的对象。然而按照你的逻辑，“罚款”也是一个整数，那么当给你一个整数的时候，你怎样知道这个整数的类型？
面向对象不是把什么都叫做对象，但是至少对于你的类型中的核心的、应该被独立认识的东西设计为对象。而你的工资类只是聚合了一些函数处理一些整数，从程序上其实不能直接看出它是干什么的，只能靠你自己的注释才知道它是应用在什么地方的。而面向对象的代码成文自明，因为他的主要类型都是从领域知识中分析出来的，而不是太在意计算机知识中才有的概念，例如它关心“工资”这个概念，而不是你说的“工资类”。 你可以把对象看作现实中应该独立存在的某种实体或者观念，多个对象并行地运行，就像物理中的“原子”或者社会中的“组织”，都是从看似有生命周期的个体的角度去考虑问题。肯定不会使用简单的计算机值类型去表达对象，而从用户创立的计算机本没有的类型去表达（封装）。考虑现实社会中这些个体如何独立存在、相互协作、发生变化，不要使用计算机领域的概念去分析需求。面向对象分析，不但可以给计算机使用，更可以给人使用，作为反映行为科学的工具。面向对象设计的代码要尽量与面向对象分析风格保持一致，才会让你的代码容易阅读、优化和扩展。面向对象程序的优化往往是在实际架构上优化，而不是死抠几个语句的CPU运行时间去优化，结构优化往往带来巨大的改变，就好像一个人突然对某个行业的认识入门了，他的结构就改变了。 引用 69 楼 viki117 的回复:
就是2个人在生孩子。。。然后越生越多。。。就成了人类。。
然后人类创造了很多东西。。就成了世界。。
把所有类想成是人，人有不同的属性，但是有固定的父母
事件函数就是人的能力和拥有的东西。。
哈哈。。我现在的抽象化的理解。。不知道是不是很傻啊。。。
这不是抽象，这是组合。人分男人女人，每一男人也同时是人，这才是基本的抽象。
很少有必要这样。实际上，收费方式可以作为一个对象类，也就是说收费方式本身的属性标记了各个计算要点，它的方法用来施行计算任务。三种收费方式实际上只是三个收费方式的实例，每一个都有各自的属性值。
看，用自然的面向领域的概念，可以让你少些冗余概念，提前按照行业中的行为方法进行动态分析。划分类型是静态分析，面向对象分析还要重点深入到的对象的变化规律中进行状态、功能、约束等分析。大多数程序员容易理解静态分析，但是不太理解动态分析技术。 种收费方式实际上只是三个收费方式的实例 --> 种收费方式实际上只是收费方式的三个实例
实际上，对象往往在现实生活中作为独立的个体，然后对这些个体分类，然后考虑类型将来如何扩展。 引用 403 楼 nodman 的回复:
可能每个人对OO的理解都不同。我说说我的看法：
从C++的角度看，OO的核心思想有3：
1.多态 polymophism
2.继承 inheritance
3.封装 encapsulation
我个人对OO最白话的理解就是：每一个对象要做到‘自己的事情自己干’
如果全部在对象外部操作对象的属性，就成了伪OO了 :)
后两句我非常同意。如果我教一个人从仅了解c#编程到OOA，我会让他忽视所有static变量和方法，并且任何方法都不能有参数，也没有返回类型。这也许从编程角度比较痛苦，但是它反映了面向对象的初衷——自己的事情自己干，对象之间仅通过暴露的（无参数）属性通讯。 个人觉得,看.net中的类就知道了.面向对像最基本的应用就是把有相同对像功能与特征的属性,方法等归纳成一个对像整体(类).
然后,我们可以在这个基础上进一步扩展,或封装.(如object到其它任何类型,又如Control到Button到自定义Button).
面向对像是一种看待程序流程中各种不同事物的方法,程序员要做的就是,把一个个独立的现象归纳为自己认为最合适的对像与流程的结合体.
例如,你要做一个3D动画,里面有很多不同的人,你就要总结,这个人可以看做一个对像,这时,你就要先做一个3D人物模型,你就必须先将这个人的基本模型建立出来,然后,你还要让这个人物模型的关节可以活动等等,最后,完成的这个人物模型就是一个对像,你可以开放设置它的身高,开放设置它的脸型,性别,等等,当然,你也可以给它加上技能(例如可以驾车,会炒菜,貌似像游戏了).
这就是面像对像的基本,因为这是很容易实体化的实体对像,其实还有很多较抽像的对像,如某件事故,某个动作等等. 前两天老板给布置任务的时候也在强调面向对象和面向过程的问题，正好看到此贴，看完后有些晕，但是好像也似乎有些明白了什么，还得继续学习中。任重而道远啊~ 我也说说，面向对象其实根据人的思维方式的定的。比如你说话：你可以看成一个对象，说的话可以看成方法，对象调用方法而已，当然这个方法是可以重用的，具体怎么样去实现只是面向过程。
仅仅是个人见解！ 这些让我想起了过度设计模式.我觉得一切得为项目实际情况考虑.有些东西在开发中,并不会考虑太多 呵呵，找本面向对象的基础书看看，说实在的，我做面向对象的东西也不短了，让我说，我还真的解释不清楚 需求唯一不变的是：它永远在变化。
面向对象跟据我的理解有两个阶段：
需求阶段的面向对象：领域模型
设计阶段的面向对象：UML图（CLASS图，Squences图.....）（7 武士）
实现阶段的面向对象：UML图的代码实现 我看到过一段话，意思是电脑程序喜欢面向对象地看待问题，但现实中的物体之间的关系更像是一张错综复杂的网
也就是要用OO的意思，但要映射成实际的流程，就像COM是一种架构，但实现还是用的一个个的DLL，光一堆DLL文件放你面前你咋一看是无法区分是第一堆没有关联的DLL还是一COM系统的集合。 引用 20 楼 wanghui0380 的回复:
看来你真的没明白对象。
从结果来看任何程序都是过程的，因为从数据输入-查找运算-显示结果肯定是一个具体的过程。
对象实际上一种编程思想，而并非啥Bil，Dal层，那个是对象的结果而已。
实际对象说穿了就是封装变化和类重用。而不是啥3层N层。
有道理 爬了400多楼，花了一个小时终于把帖子看了大概，值得好好探讨探讨。
面向对象是一种思想，这点认同，可是好像我们在写程序的时候不知不觉就变成了面向过程了，
要怎样才能有真正面向对象的思想了？
个人理解，面向对象和面向过程本身并没有优劣之分，各自有各自的特点。有些东西或者项目，用过程的思想解决就足够了，因为他变化少；有些东西或者项目，光靠面向过程来解决是不行的，因为里面有太多的变化需要面向对象的思想来封装。
所以个人认为，面向对象的思想是用来封装变化的。
所以，并不是说你按着petshop里面写一个Model模块，就是所谓的面向过程了，这个不过是面向过程需要的一部分而已。
所以我也认为，倘若我们单纯的对某一个项目的开发或者设计采用面向对象或者面向过程的思想来做判断，似乎有些偏颇。
作为开发人员，我们不可能预测所有的变化，从而也不可能完美的实现每一处的封装。我们更多的只是做一些可能的部分预测，最终导致，程序某些地方实现了封装，有些地方没有实现封装。
我个人这样认为，现在的项目，大部分都是过程和对象的混合开发。我们不可能做到完全的面向对象的开发，面向对象是用来解决某些可能问题的，面向对象离开不了面向过程，过程是对象的基础。
所以我不评价那些所谓的经理或者其他高级人士的评判是否正确，因为那都不重要。 花了2个小时看完所有回复。 太部分人都在说自己对oop的理解，并举了现实化的例子,OK 我算你明白了概念又如何。
什么猫狗人 属于什么基类！但我们在编程的时候往往到头来依然是使用面向过程。我也是一直这样，概念我完全明白。
明明知道盖世武功有多厉害(oop概念)，自己也学会了(理解了oop)，但他. 妈 杀. 人的时候就是使不出来(做项目时用不出来)！
上面就是我现在面对oop的情况！我知道我需要经验累积！
请问应该如何封装变化？
请高手就 24 楼 的举例给个例子我们新手看看 我认为 这些的一切都是解决开发速度
要解决开发速度就是要让最大程度代码重用
先设置的时候不可能考虑到以后的变化。所以只要需求变化，就要修改代码 不管是面向对象还是面向过程
做一个运算，就是两部分 一部分是参数或者是环境 另一部是实现的具体方法获知是函数
在面向对象的时候把 参数和环境对通过 属性来存储 由方法来实现
然后把 具有一定类型的事物定义成一个类 其他就只需要调用，当事物发生变化后 只需要修改这个类，而不需要修改类外面的东西 减少代码的修改量。 所以当计算方式改变了 就这个在类中增加一个方法。
只是个人看法，
我理解的面向对象其实归根结底就是一个字,类!类才是对象的根!没类就谈不上面向对象...大家喷我吧~嘎嘎~~~~~ 引用 27 楼 SkyIsland 的回复:
非常感谢[一水寒]的指点。
你的讲解给我的第一印象是，需求无限的变化，而我们要考虑未来的变化来设计现在的东西。是啊，怎么办呢？如果未来有100种需求，难道我们现在就要事先想好所有的变化吗？对于这方面您有什么好的想法？
我现在只能通过无限修改代码的方式来解决这个问题，比如说，有一张表，你通过子查询的方式可以有千变万化的View，用户今天要一个View，我加一个，明天又要另一个View，我又加一个。目前为止，我…
我是一个初学者，我是一开始就接触面向对象的思维的，目前尝试的学习工具是D2006中ECOIII平台，大体上我对面向对象开发方式的优点理解为：
1、分析过程较为贴进现实世界对“对象”的概念理解，楼上有人说初学者可能不太容易理解“面向对象”，在我看来，感觉上“面向对象”更容易被初学者理解（我这里说的“初学者”指我这样的白纸类型的初学者），整个分析过程是在讨论每一个对象具有的属性与行为及各个对象之间的相互关系，而不是在讨论函数调用或什么程序段调用，也不用讨论表结构的设计，不用讨论不同数据库产品之间的差异问题（分析设计过程与具体数据库无关），不用讨论对表如何访问的问题（面向对象的分析设计中讨论的是对“对象”的访问，比如OCL语言就是一种以对象为目标进行访问的语言，而SQL是一种对表进行访问的语言），至少在我个人看来，访问一个“对象”比访问一个“表”更贴合我对现实事物的理解
2、面向对象的分析方式其描述过程更容易与客户代表在项目进程的早期阶段就进行深入的需求沟通，传统方式则往往需要做DEMO，而一个较复杂的系统，DEMO是很难直接说明界面背后的复杂逻辑关系的，客户代表也极难看得懂你的代码（基本上不可能），但面向对象的分析模式会留下类似机械设计工程中的设计图纸，需要管理的各个实体对象、各个实体对象各自的属性与行为、各个对象之间的关系、各个事件流的目的性、每个事件流涉及到的对象及事件流的过程都可以图纸化、档案化的保存下来，而用这种图纸加文字的档案与客户代表进行交流很显然比用程序代码或DEMO来跟客户代表进行交流会具备更多的可沟通性
3、具体到设计代码这个工作层次时，类的高度抽象导致类的可重用性很高，工作重复性大大降低，不同项目使用相同的历史工作积累的可能性大大增加，面向对象的分析过程中的一个重要特点就是抽取多个对象的共性形成抽象类，由于各个不同项目中总会存在大量的类似的抽取共性的工作，这样在一个项目中抽取过的抽象类在另一个项目中很可能根本不需要改动就直接能拉过去用了，而在一个项目中分析过的实体类，也很可能在另一个项目中只是有少量的属性/行为的增加或减少，那么也可以把这个项目中的实体类拿到另一个项目中，给它增加或减少一些属性/行为就可以了，甚至有可能是一个项目中的一个包（包含了很多类及类关系的包）都可以拿到另一个项目中只需要对其中少量的类进行属性/行为的修改就可以用了，当然也可以根据新的需求修改包里面各个类之间的关系了，总之，你不需要进行全面的重新分析设计，不用换一个项目就必须重新考虑数据库该怎么重新搞过，界面你可以根据新需求另行更换过
也就是说，面向对象的设计模式，你大部分的时间是在考虑业务逻辑是否设计正确了，比如你需要大量的考虑诸如以下这样的问题：
1、我设计的事件流是否有清晰的目的性，这个目的性是否为客户代表确认为有存在必要的
2、事件流中涉及的对象是否为客户代表认为实际存在的或有必要存在的
3、各个对象（类）的属性/行为及他们之间的相互关系及状态变化是否能被客户代表理解与接受
4、各个对象之间是否还存在可以抽取的共性
5、客户代表希望访问各个对象的什么信息，以什么样的形式体现
嗯，我自己刚做了一个小例子，呆会发个图上来跟大家讨论讨论 图1，是为了实现一个用户对计提规则进行自定义的要求而设计的ER图
图2，是程序运行结果
1、首先是根据用例分析出所需管理的几个实体对象，分析各个实体对象应该具备的属性与行为，再从这些实体对象中抽象出“事物”这个抽象类（这个例子中各个实体类都具有“名称”与“编号”这两个属性，所以提取出来一个抽象
三 : BCD编码为什么叫8421码？
BCD编码为什么叫8421码？
BCD采用四位编码代表一个十进制或十六进制数字，最高位为1代表8，其后依次为4、2、1，然后把这些值加起来就是它所代表的那个数字。BCD编码abcd可以用公式8a+4b+2c+d来表示（其中a、b、c、d只能取0或1）
比如BCD编码0110，代表0*8+1*4+1*2+0*1=6
本文标题：
什么叫做面向对象编程-什么叫做面向对象? 本文地址：
http://www.61k.com/1161400.html 