作者：二律背反
链接：https://www.zhihu.com/question/305042684/answer/557460817
OOP有且只有一个价值：应对需求的变化。
哪里的需求有变化，哪里就要OOP；哪里的需求不变，哪里就不需要OOP。一个hello world我可以一句话搞定、也可以写四五个class用两三种设计模式去实现，我不是吃饱了撑的，而是因为我的客户告诉我需求会发生变化：比如今天hello world在终端显示、明天要换到GUI显示、后天要用socket发到另一台机器上显示………
换句话说，如果需求永远不变，OOP除了加了代码的阅读难度外，没有任何价值。
从取舍的角度来说，OOP就是用“纵向增加代码的复杂度”换取“对代码进行增删改时的最小工作量”。（元编程是横向增加）
如果你面对一个一万年也不会发生变化的需求，其实面向过程更好：不论从代码效率还是代码的可读性上来说。
需求：开发一个计算器。
OOP的价值是：它可以让你先开发出加减乘除，然后走测试甚至交付给用户开始使用；后面你可以继续开发乘方、求余、对数等功能。在你进行后续的这些开发时，你对之前已经开发好的加减乘除的代码的改动最小（几乎不用改），或者这样说：加减乘除的代码对你后续新增的代码是无感知的。
如果用户说，你就给我开发个实现加减乘除的计算器，我以后绝对不会改需求，如果我食言我就把合同吃了，那么，请你直接用最普通的面向过程开发吧，你甚至连函数都不需要写、全部塞到main函数都行。
为了OOP而OOP的人，都是想不开的人。
我还见过一些“大神”写那些一万年也不会改或者就用两天就废弃的bash脚本，一堆function、模块化设计，读他们的脚本要切换来切换去，搞的人眼花缭乱……对此我只能说，你想自虐请自便但是别拉我一起好吗？bash脚本，就简简单单从第一句写到最后一句不好吗？所以在这里顺便对一些“大神”说一句：放过我们吧……
另外，把OOP理解为“以数据为中心、为对象”，没有错不过不够彻底不够本质，这只是初学者的理解，函数一样可以OOP，lambda了解下？直接把OOP理解为“解耦”或者“为变化服务”更好一些。
如果你上面都看懂了，再回头看下面这些非常官方的话，你应该就秒懂了：
面向对象的三大特点是封装、继承和多态（为啥要封装为啥要继承为啥要多态？一句话：就是为了强化你代码应对变化时的适应能力，比如有人觉得private public这些东西都没用，你会觉得没用是因为你没开发过大型的软件、没解决过频繁变化的需求）。
结构化设计方法将审视问题的视角定位于不稳定的操作之上，并将描述客体的属性和行为分开，使得应用程序的日后维护和扩展相当困难，甚至一个微小的变动，都会波及到整个系统。面对问题规模的日趋扩大、环境的日趋复杂、需求变化的日趋加快，将利用计算机解决问题的基本方法统一到人类解决问题的习惯方法之上，彻底改变软件设计方法与人类解决问题的常规方式扭曲的现象迫在眉睫，这是提出面向对象的首要原因……
作者：铁原
链接：https://www.zhihu.com/question/305042684/answer/692966396
所有只是从OOP本身特性，语法等角度聊OOP的，都是不可能触达问题实质的。
因为OOP只是解决“某个问题”的手段的一种“相”而非所有相。见诸相非相，即见如来。
OOP产生的背景是计算机软件行业大发展，软件的种类和规模复杂度都急剧提升。原始的汇编和c语言等方式已经难以满足大规模工程化的要求了。软件行业急需一种工程化的工具来满足这种软件开发的要求。它要求软件行业能够像搭积木一样的组装出任意复杂度和规模的软件出来，这就是“组件化思想”（或者说模块化思想）。
OOP是组件化思想的一种体现，但并非唯一一种体现，譬如还有MFC，SOA，微服务……等。不用管名词是什么，粒度是什么，其实他们本质都是一个东西——分而治之。这种思想得以实施的一个前提是复杂度内部的耦合度和抽象。
组件化思想的目的是向上层屏蔽复杂性。所以这就意味着它的前提必须是基于耦合性和抽象的。如果不基于耦合性，则必须将内部错中复杂的关系暴露给上层——这是违反屏蔽复杂性目的。如果不基于抽象，而基于具体，则任何具体的变化会导致所有依赖这个组件的软件产生联动，这同样违反向上层屏蔽复杂性。
这里基于内聚性，大家都知道，都会努力做，只不过做的好不好而已。但是第二条，其实做到的并不多。面向对象编程圈同样有另外一个遗毒甚广的原则“复用”，甚至很多开发跟我说OO的精髓就是复用。代码里有点相似的东西，就考虑复用。我强调一下：复用的前提是抽象，N个业务线某几块代码是相似的，你复用了，如果不是基于抽象的复用，而只是单纯的复用，那么任意一个业务线的逻辑变化导致共有快逻辑变化的将是一个巨大的风险。这在太多的企业都是常见的，也是这个错误原则遗毒甚广的体现。在这种情况下，复用不如面条式的代码。（可以说，现实情况下大多数情况下，应该都不如），真正能从业务模块抽象出能隔离具体，隔离变化的共有模块是非常难的。不是简单的代码复用就可以做到的。
流毒甚广的OO三原则：封装，继承，多态，为什么说他们流毒甚广呢？上面我们提到的东西，就是更基本的原则。其中只有封装是对的，继承和多态在很多情况下问题都颇多。有兴趣的可以百度下。
只有理解了程序的复杂性，和解决复杂性的手段，以及这个手段和OOP之间的关系，才算是基本了解了OOP的本质。
这里面有很多较细的情况
1. 程序都是复杂性的么？
2. 复杂性必须只能用OOP解决么？如过不是，什么情况下OOP合适？哪些情况其他 ？
3. OOP解决的真正有效的手段是什么？有哪些是谬误的，或者问题比较多的，如何规避？
作者：大宽宽
链接：https://www.zhihu.com/question/305042684/answer/550196442
面向对象编程（OOP），是一种设计思想或者架构风格。OO语言之父Alan Kay，Smalltalk的发明人，在谈到OOP时是这样说的：
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).
...
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP.
简单解释一下上面的这几句话的大概意思：OOP应该体现一种网状结构，这个结构上的每个节点“Object”只能通过“消息”和其他节点通讯。每个节点会有内部隐藏的状态，状态不可以被直接修改，而应该通过消息传递的方式来间接的修改。
这个编程思想被设计能够编写庞大复杂的系统。
那么为什么OOP能够支撑庞大复杂的系统呢？用开公司举个例子。如果公司就只有几个人，那么大家总是一起干活，工作可以通过“上帝视角“完全搞清楚每一个细节，于是可以制定非常清晰的、明确的流程来完成这个任务。这个思想接近于传统的面向过程编程。而如果公司人数变多，达到几百上千，这种“上帝视角”是完全不可行的。在这样复杂的公司里，没有一个人能搞清楚一个工作的所有细节。为此，公司要分很多个部门，每个部门相对的独立，有自己的章程，办事方法和规则等。独立性就意味着“隐藏内部状态”。比如你只能说申请让某部门按照章程办一件事，却不能说命令部门里的谁谁谁，在什么时候之前一定要办成。这些内部的细节你管不着。类似的，更高一层，公司之间也存在大量的协作关系。一个汽车供应链可能包括几千个企业，组成了一个商业网络。通过这种松散的协作关系维系的系统可以无限扩展下去，形成庞大的，复杂的系统。这就是OOP想表达的思想。
第一门OOP语言是Ole-Johan Dahland和Kristen Nygaard发明的Simula（比smalltalk还要早）。从名字就可以看出来，是用来支撑“模拟系统”的。模拟这个场景非常适合体现OOP的这个思想。这个语言引入了object、class、subclass、inheritance、动态绑定虚拟进程等概念，甚至还有GC。Java很大程度上受了Simula的影响。我们在现在教书上讲解OOP类、实例和继承关系时，总会给出比如动物-猫-狗，或者形状-圆-矩形的例子，都源自于此。
还有一些带有OO特征的语言或者研究成果在Simula之前就出现，这里就不往前追溯了。
但随后在施乐Palo Alto研究中心（Xerox PARC），Alan Kay、Dan Ingalls、Adele Goldberg在1970年开发了smalltalk，主要用于当时最前沿计算模型研究。在Simula的基础之上，smalltak特别强调messaging的重要性，成为了当时最有影响力的OOP语言。与smalltalk同期进行的还有比如GUI、超文本等项目。smalltalk也最早的实现了在GUI使用MVC模型来编程。
但是，并不是说OOP程序一定要用OOP语言来写。再强调一下，OOP首先是一种设计思想，非仅仅是编码方式。从这个角度推演，其实OOP最成功的例子其实是互联网。（Alan Kay也是互联网前身ARPNET的设计者之一）。另外一个OOP典型的例子是Linux内核，它充分体现了多个相对独立的组件（进程调度器、内存管理器、文件系统……）之间相互协作的思想。尽管Linux内核是用C写的，但是他比很多用所谓OOP语言写的程序更加OOP。
现在很多初学者会把使用C++，Java等语言的“OOP”语法特性后的程序称为OOP。比如封装、继承、多态等特性以及class、interface、private等管家你在会被大量提及和讨论。OOP语言不能代替人类做软件设计。既然做不了设计，就只能把一些轮子和语法糖造出来，供想编写OOP程序的人使用。但是，特别强调，是OOP设计思想在前，OOP编码在后。简单用OOP语言写代码，程序也不会自动变成OOP，也不一定能得到OOP的各种好处。
我们在以为我们在OOP时，其实很多时候都是在处理编码的细节工作，而非OOP提倡的“独立”，“通讯”。以“class”为例，实际上我们对它的用法有：
表达一个类型（和父子类关系），以对应真实世界的概念，一个类型可以起到一个“模版”的作用。这个类型形成的对象会严格维护内部的状态（或者叫不变量）
表达一个Object（即单例），比如XXXService这种“Bean”
表达一个名字空间，这样就可以把一组相关的代码写到一起而不是散播的到处都是，其实这是一个“module”
表达一个数据结构，比如DTO这种
因为代码复用，硬造出来的，无法与现实概念对应，但又不得不存在的类
提供便利，让foo(a)这种代码可以写成a.foo()形式
其中前两种和OOP的设计思想有关，而其他都是编写具体代码的工具，有的是为了代码得到更好的组织，有的就是为了方便。
很多地方提及OOP=封装+继承+多态。我非常反对这个提法，因为这几个术语把原本很容易理解的，直观的做事方法变的图腾化。初学者往往会觉得他们听上去很牛逼，但是使用起来又经常和现实相冲突以至于落不了地。
“封装”，是想把一段逻辑/概念抽象出来做到“相对独立”。这并不是OOP发明的，而是长久以来一直被广泛采用的方法。比如电视机就是个“封装”的好例子，几个简单的操作按钮（接口）暴露出来供使用者操作，复杂的内部电路和元器件在机器里面隐藏。再比如，Linux的文件系统接口也是非常好的“封装”的例子，它提供了open，close，read，write和seek这几个简单的接口，却封装了大量的磁盘驱动，文件系统，buffer和cache，进程的阻塞和唤醒等复杂的细节。然而它是用函数做的“封装”。好的封装设计意味着简洁的接口和复杂的被隐藏的内部细节。这并非是一个private关键字就可以表达的。一个典型的反面的例子是从数据库里读取出来的数据，几乎所有的字段都是要被处理和使用的，还有新的字段可能在处理过程中被添加进来。这时用ORM搞出一个个实体class，弄一堆private成员再加一堆getter和setter是非常愚蠢的做法。这里的数据并非是具有相对独立性的，可以进行通讯的“Object“，而仅仅是“Data Structure”。因此我非常喜欢有些语言提供“data object”的支持。
当然，好的ORM会体现“Active Record”这种设计模式，非常有趣，本文不展开
再说说“继承”，是希望通过类型的 is-a 关系来实现代码的复用。绝大部分OOP语言会把is-a和代码复用这两件事情合作一件事。但是我们经常会发现这二者之间并不一定总能对上。有时我们觉得A is a B，但是A并不想要B的任何代码，仅仅想表达is-a关系而已；而有时，仅仅是想把A的一段代码给B用，但是A和B之间并没有什么语义关系。这个分歧会导致严重的设计问题。比如，做类的设计时往往会希望每个类能与现实当中的实体/概念对应上；但如果从代码复用角度出发设计类，就可能会得到很多现实并不存在，但不得不存在的类。一般这种类都会有奇怪的名字和非常玄幻的意思。如果开发者换了个人，可能很难把握原来设计的微妙的思路，但又不得不改，再稳妥保守一点就绕开重新设计，造成玄幻的类越来越多…… 继承造成的问题相当多。现在人们谈论“继承”，一般都会说“Composite Over Inheritance“。
多态和OOP也不是必然的关系。所谓多态，是指让一组Object表达同一概念，并展现不同的行为。入门级的OOP的书一般会这么举例子，比如有一个基类Animal，定义了run方法。然后其子类Cat，Dog，Cow等都可以override掉run，实现自己的逻辑，因为Cat，Dog，Cow等都是Animal。例子说得挺有道理。但现实的复杂性往往会要求实现一个不是Animal的子类也能“run”，比如汽车可以run，一个程序也可以“run”等。总之只要是run就可以，并不太在意其类型表达出的包含关系。这里想表达的意思是，如果想进行极致的“多态”，is-a与否就不那么重要了。在动态语言里，一般采用duck typing来实现这种“多态”——不关是什么东西，只要觉得他可以run，就给他写个叫“run”的函数即可；而对于静态语言，一般会设计一个“IRun”的接口，然后mixin到期望得到run能力的类上。简单来说，要实现多态可以不用继承、甚至不用class。
OOP一定好吗？显然是否定的。回到OOP的本心是要处理大型复杂系统的设计和实现。OOP的优势一定要到了根本就不可能有一个“上帝视角”的存在，不得不把系统拆成很多Object时才会体现出来。
举个例子，smalltalk中，1 + 2 的理解方式是：向“1”这个Object发送一给消息“+”，消息的参数是“2”。的确是非常存粹的OOP思想。但是放在工程上，1 + 2理解为一般人常见的表达式可能更容易理解。对于1 + 2这样简单的逻辑，人很容易从上帝视角出发得到最直接的理解，也就有了最简单直接的代码而无用考虑“Object”。
如果是那种“第一步”、“第二步“……的程序，面向数据的程序，极致为性能做优化的程序，是不应该用OOP去实现的。但很无奈如果某些“纯OOP语言”，就不得不造一些本来就不需要的class，再绕回到这个领域适合的编码模式上。比如普通的Web系统就是典型的“面向”数据库这个中心进行数据处理（处理完了展示给用户，或者响应用户的操作）。这个用FP的思路去理解更加简单，直观。也有MVC，MVVM这样的模式被广泛应用。
还有一些领域尽管用OOP最为基础很适合，但是根据场景，已经诞生出了“领域化的OOP”，比如GUI是一个典型的例子。GUI里用OOP也是比较适合的，但是GUI里有很多细节OOP不管或者处理不好，因此好的GUI库会在OOP基础之上扩展很多。早期的MFC，.Net GUI Framework, React等都是这样。另外一个领域是游戏，用OOP也很合适，但也是有些性能和领域细节需要特殊处理，因此ECS会得到广泛的采用。
总结一下，OOP是众多设计思想中的一种。很多OOP语言把这种思想的不重要的细节工具化，但直接无脑应用这些工具不会直接得到OOP的设计。即便是OOP思想本身也有其适合的场景和不适合的场景。即便是适合的场景，也可能针对这个场景在OOP之上做更针对这个场景需求的定制的架构/框架。如果简单把OOP作为某种教条就大大的违反了这个思想的初衷，也只能得到拧巴的代码。
