问一个很抽象的问题，面向对象的，思想家们停下脚步

[一入程序深似海]

怎么去才算理解了面向对象？如何去理解 领域驱动设计（DDD）？

刚刚大学毕业，对面向对象的理解还是不够深刻。
面向过程的思想似乎根深蒂固了，对于一个需求，总是习惯用过程去解决，而非面向对象。
需求（输入）----->操作----->结果（输出）
仅仅是把操作中的行为和操作实体class化，似乎不是面向对象。
怎么才算理解了“面向对象”？
对于一个需求，如何去进行领域驱动设计？
万物皆对象，感觉太飘渺了。

[一入程序深似海]

引用 15 楼 lvjing_CSDN 的回复:

我觉得面向对象的设计就是：先考虑事物自身的运行方式，然后对其运行方式分段（如同对小学课文分段，呵呵，实际上这里的每个段都是我们后面的一个类），之后找出各个段之间的交互（即各个类直接的接口）。最后把这些段抽象为各个类，类的接口即我们前面找出的段之间的交互。如果是用面向过程的设计的话，我觉得可能就不需要分段，就是按照其运行方式一步一步的来进行设计，一旦某个步骤设计不对可能会影……

这就是领域建模吗？

[一入程序深似海]

引用 21 楼 ardayoyo 的回复:

引用 20 楼 CKnightx 的回复:多态是面向对象，好像有点感觉，但是后面一句却不能理解。为什么函数是面向对象最重要的？… 这不仅仅是面向对象的重点，也是所有编程的重点啊，函数（解决方法）永远是核心么

方法是类的重点，这个知道，这个只是实现上。但在实现之前，按怎样的思想，把方法放在什么一个类下（也是就设计）我不了解。

[sniffer12345]

引用 20 楼 CKnightx 的回复:

引用 17 楼 sniffer12345 的回复:引用 16 楼 stereoMatching 的回复:忘了回答你什么是面向对象 其实什么是面向对象，我从来都没有真的弄懂过 这东西你问十个人大概会得出15种不同的答案 我只知道多态，封装，is a, has a, is implemented in terms of 一些design patterns--strat……

不知道。。大牛们都这么说 我就跟着这么说啦嘿嘿 纯OO的也有，诸如ruby，连数字比如1,2,3,4,5都是object，可以这样使用：3.times { print "X " }。但这些并不意味着优雅。说实话我觉得有点别扭 用过那么多语言，我觉得堪称漂亮的就是js。以函数为单位，设计围绕着函数，同时天生支持lambda。如果你再了解什么叫可重入，意识到设计的时候尽量用标量而不是向量，再加上基于函数的单元测试，整个系统可以轻松达到松耦合。 当然一家之言，大家讨论讨论

[走好每一步]

楼主想的问题我之前也有想过。现在还是很懵懂： 1、不要为了面向对象而对象，如果公司很小，奉劝不要对象啦，首先要速度解决问题才是最关键，立马产生经济效益才是最重要的，其它的可以往边靠。 这就是为什么有些程序员玩的是c++，写的是面向过程，但是却可以拿着高工资。 2、公司发展到一定程度，单很多，却忙不过来。这时可考虑招码农过来，划分好功能和接口，让别人帮你做。这时候还是面向过程好，可控！！！ 3、公司有一定规模，单很多，而且程序核心不变，功能需求不同，可以进军面向对象。在不增加大量码农的情况下，可以很好地满足不同层面客户的需求。 我觉得类最大的贡献就是数据的封闭性。面向过程总是诱导某些程序员试图插手别人模块的东西，全局变量漫天飞，很快这段程序就废掉了。当然如果公司制度文档够好的话，倒不会有太大问题。 面向对象最大的危险就是万能类。为了对象而划分一堆不知所云的类，这也是我以前常犯傻，说心里话，似是而非面向对象其实真的很不可控的！！！ 觉得做程序就像完成一件事情一样，怎么划分才是合理，而且角色固定后，即使事情再怎么变化，领导者不在场，都不会出乱子。 楼主可以参考下公司结构，应该会有所启发。 比如完成一个订单 面向过程：老板叫人去买货，买货回来还要看下货物，做账。又安排人测试，打包，然后让人联系快递发货。老板这样生病都生不起。 面向对象：业务把单发给——》财务 业务把单发给-》采购 中间只需老板和经理浏览下单和签名就ok了。 财务收到款项通知采购，采购拿着单向财务要钱-》财务 采购去买货-》仓库 仓库通知->QC 测试。 QC测好放回-》仓库 仓库通知-》业务 业务-》发货部 发货部问财务款收齐了没-》财务 发货~~~~~ 整个过程老板只需签字一次，数额不大可能都不会理，这笔单就自动完成了。 就像程序模块划分得好，接口定义得好，可能你有事或者生病了，随便叫个人来帮忙都ok的。或者你有了小弟，叫几个小弟帮你弄，根本不用你操心。

[stereoMatching]

引用

方法是类的重点，这个知道，这个只是实现上。但在实现之前，按怎样的思想，把方法放在什么一个类下（也是就设计）我不了解。

没人能教你该怎么设计，就算是Bjarne也办不到 怎么设计只能靠自己，多写多读多想

[走好每一步]

比如你公司接了很多单子 搞界面的人只有一个。接口定得好的话，搞界面的人就搞界面就好了，搞了这个接着搞另外一个，他不会去关心整个程序是什么样子的，也不需要。 同样 后台也一样。 我们看下面向过程和面向对象的区别。 比如叫人QC 面向过程的话你可能会考虑要让多少人来测，告诉那些人怎么测，面向对象的话只要把要求告诉QC主管，剩下的问题让主管考虑去。 同样，用面向过程写的界面，假如我是功能实现者，需要用到界面，那么只有黏贴界面函数吧，这样我就又得学会界面的东西了，而且如果我觉得界面不舒心，我又改一下，说不定连名字都改了。以后假如客户要换界面，是不是除了改界面程序员那部分，还要改我这部分，工作量是非常庞大啦。但是假如是面向对象，就不需要了。每个人职责分明，不能越界！！

[走好每一步]

[一入程序深似海]

引用 25 楼 tajon1226 的回复:

楼主想的问题我之前也有想过。现在还是很懵懂： 1、不要为了面向对象而对象，如果公司很小，奉劝不要对象啦，首先要速度解决问题才是最关键，立马产生经济效益才是最重要的，其它的可以往边靠。 这就是为什么有些程序员玩的是c++，写的是面向过程，但是却可以拿着高工资。 2、公司发展到一定程度，单很多，却忙不过来。这时可考虑招码农过来，划分好功能和接口，让别人帮你做。……

我就职的公司，核心内容应该不会怎么变。虽然我完全可以面向过程一直呆着，但是我忍受不了这种没有创造力的体力活。我想提高自己。 现在我是码农，我必须承认，但是我不想5年后，还是码农。 做技术的，在待遇还算满意的条件下，希望得到的是被肯定，是吧？ 若干年后，假设公司还在，还能赚到钱，我要是就靠着自己在公司的时间长而呆着，我会自己瞧不起自己。 近3个月，我一直在看设计模式，尝试去理解，如何才算理解面向对象了，如何才能把自己的代码写得更简洁易懂。我目前是在维护之前的代码，栽过坑，看不懂作者意图…加上对技术的追求，现在想这些事情想得很多。扯远了。。 我发这个帖子，旨在请教前辈们，在面向对象的路上，前辈都是怎么过来的，恳请前辈们分享一下经验。至于公司的业务，产品的性能，是另外的话题了。 昨天晚上跟公司牛人也讨论了一下，先学会建模，再用设计模式来优化模型，从这个过程里面去理解面向对象。 你们都是这么过来的吗？

[一入程序深似海]

引用 26 楼 stereoMatching 的回复:

引用方法是类的重点，这个知道，这个只是实现上。但在实现之前，按怎样的思想，把方法放在什么一个类下（也是就设计）我不了解。 没人能教你该怎么设计，就算是Bjarne也办不到 怎么设计只能靠自己，多写多读多想

我同意你说的，要靠自己。 所以现在请教你们大牛，是怎样去理解OO的嘛

[一入程序深似海]

引用 24 楼 sniffer12345 的回复:

引用 20 楼 CKnightx 的回复:引用 17 楼 sniffer12345 的回复:引用 16 楼 stereoMatching 的回复:忘了回答你什么是面向对象 其实什么是面向对象，我从来都没有真的弄懂过 这东西你问十个人大概会得出15种不同的答案 我只知道多态，封装，is a, has a, is implemented in terms of 一些d……

简单，实用才是优秀的。 C++有C++的长处，Java也有Java的优势。不能拿一个领域，来讨论所有的语言。 语言只是工具，用工具解决问题，才是根本，是吧？ 欢迎继续讨论 OO，如何去理解OO

[qq120848369]

看优秀的开源代码吧。。。我觉得设计模式太学术了，优秀的开源项目里到处都是设计模式，就怕你发现不了。

[lvjing_CSDN]

引用 22 楼 CKnightx 的回复:

引用 15 楼 lvjing_CSDN 的回复:我觉得面向对象的设计就是：先考虑事物自身的运行方式，然后对其运行方式分段（如同对小学课文分段，呵呵，实际上这里的每个段都是我们后面的一个类），之后找出各个段之间的交互（即各个类直接的接口）。最后把这些段抽象为各个类，类的接口即我们前面找出的段之间的交互。如果是用面向过程的设计的话，我觉得可能就不需要分段，就是按照其运行方式一……

额，不懂领域建模。

[走好每一步]

引用 32 楼 qq120848369 的回复:

看优秀的开源代码吧。。。我觉得设计模式太学术了，优秀的开源项目里到处都是设计模式，就怕你发现不了。

呵呵，同感。面向对象只是一种做事的方法和思想，并不是某种语言特有的。总感觉书本有种把面向对象妖魔化的趋势，然后不知所云地讨论万物皆对象。 楼主，当你有你能力安排码农干活的时候，那你就不是码农了，而且这种能力跟技术无关。 技术牛人也是高级的码农。仅此而已。 面向对象的初衷是有效管理大工程，什么多态、复用只是衍生品罢了。看设计模式，还不如看下公司管理的书籍。 当然我现在也是夸夸其谈，因为我不是李开复，仅此而已。

[一入程序深似海]

引用 32 楼 qq120848369 的回复:

看优秀的开源代码吧。。。我觉得设计模式太学术了，优秀的开源项目里到处都是设计模式，就怕你发现不了。

+1 推荐几个适合我入手的优秀源码呗

[一入程序深似海]

引用 34 楼 tajon1226 的回复:

引用 32 楼 qq120848369 的回复:看优秀的开源代码吧。。。我觉得设计模式太学术了，优秀的开源项目里到处都是设计模式，就怕你发现不了。 呵呵，同感。面向对象只是一种做事的方法和思想，并不是某种语言特有的。总感觉书本有种把面向对象妖魔化的趋势，然后不知所云地讨论万物皆对象。 楼主，当你有你能力安排码农干活的时候，那你就不是码农了，而且这种能力跟技术无关。……

你是李开复，也许我就喷你了。。。

[qq120848369]

引用 35 楼 CKnightx 的回复:

引用 32 楼 qq120848369 的回复:看优秀的开源代码吧。。。我觉得设计模式太学术了，优秀的开源项目里到处都是设计模式，就怕你发现不了。 +1 推荐几个适合我入手的优秀源码呗

石器时代2.5源码怎么样？ 千万别把设计模式和面向对象挂钩了， 没有什么联系。 继承和多态在C里一样可以实现，这一点看看jabberd2/memcached都可以找到踪迹。

[stereoMatching]

楼主，我不知道什么是面向对象 我曾经以为我懂，但是现在我发现我根本不懂 这是什么东西，因为每个人的说法都不一样 阅读越混乱，甚至还有人在那扯什么 万物皆对象，把一切的问题都说得模棱两可 我现在是用另外一种方法来学习和思考 把每一种design patterns，paradigms 都当成一种解决问题的技术 从我所知道的方法中挑选最简单，耦合度最低的 日后需要优化或扩充时再重构就好 至于这是不是面向对象 泛型编程或面向过程等 并不是这么的重要 重要的是我在学习的过程 学会了新的技术 学会分析不同技术的优点和缺点 什么是OOP我真的不懂 generic programming我目前倒是可以说的 出来，但说不定哪一天我又会发现我不懂什么 是generic programming

[wdmcirl]

前阵子，嗯，也就是前几天吧，去面试的时候被问到干嘛线程函数在类里面要设计成static的。我没有回答得上来.... 面试回来之后就补啊，深入下去才知道原来自己学c++都一年多了还真不知道面向对象的思想是什么玩意。 我也想发帖问的，关于“一个类的设计哲学”。 计算机里面的某些东西应当是现实世界上某个集合的映射。那c++这个面向对象的语言应该提供了能完全表达这个思想的机制的。 我的思想是这么延伸的：每一个类是一个种群，而个体间的差异是通过类里面的属性设置的。然后我就想到了为什么会有static这东西，如果一个方法，可以理解为某个个体的行为，如果这个行为一旦发生就会对整个族群产生影响或者完全没有影响，那这个方法可以设置成static的（对应的是static 成员函数只能访问static成员变量，static成员变量是记录族群的变化的）.就像两个派系争斗，派系里任何一个成员捡到了宝藏宝藏都归整个派系所有。 还有多态的问题，我当时想到一个搞笑的例子。一辆车在路上走，撞到动物之后动物会发出一声惨叫，要是撞到了猪，猪嚎、撞到了牛、牛叫。猪跟牛都是从动物派生下来的。如果设计animal类的时候有那么个叫的方法，设置成虚函数，猪跟牛分别重写了这个函数。那当车撞到动物的时候只要把动物这个父类指针传过去那就能具体情况具体分析了。 以上说的只是一部分我想到的能把面向对象思想和现实世界结合起来的东西。越想越发现，有些地方能这个解释了，可是深入再思考一下就发现新的问题。所有才想到是不是存在一个“类的设计哲学”此类的东西。 和楼主一样的困惑。

[qq120848369]

天天研究动物和鱼,牛,马的关系, 永远也学不会设计模式... 实际项目里的对象交互关系远比这个值得深思.

[lm_whales]

对象这个词，是翻译失误。 应该译为物体，事物。 面向对象，面向的是问题领域，或者叫做面向现实，思考的是现问题逻辑。 实际事物是如何交互的，把这个抽象为类，以及类的接口。 面向对象，并不排斥面向过程，而是这二者相辅相成，才能完成整个设计。 面向过程面向的是程序实现领域，是面向计算机，面向计算机语言的。 先找到途径，一步一步实现，在叠加起来。 解决实际问题，思考的是实现逻辑。 设计模式，之所以不好实现，因为你想把它用于你的项目的时候； 你恰好没有设计实现（或者参与设计实现）一个项目的经验。 当你设计或者参与设计了几个项目以后，你就对设计模式有所认识了； 无论那些项目，用没有用到设计模式中的知识，对照设计模式，你都会所认识。 设计模式，不是单纯用于编写一些简短的程序玩的； 是用于设计有一定规模的项目的。 你写一点小程序，可以对C,C++语言的某些特性，对某个算法，对编程规范，产生一些了解。 但是对于设计模式，你只能知道，代码如何写，才能够实现某种模式。 对于该模式如何应用，应用到什么场景，为何用这种模式，是不起什么作用的。 虽然，书里都会讲解这些，一些关于设计模式的文章里也会提到。 但是总是如隔靴搔痒，感受不深。 这些，必须有项目的实践，和掌握一些项目，实践过程的资料，才能够有深切的体会。 大牛为何牛，除了创造性，理论功底，知识渊博外； 丰富的实践经验（参与了，乃至主持了比较多项目），才是大牛之所以牛的资本。