链接：https://www.zhihu.com/question/305042684/answer/692966396
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
OOP产生的背景是计算机软件行业大发展，软件的种类和规模复杂度都急剧提升。原始的汇编和c语言等方式已经难以满足大规模工程化的要求了。软件行业急需一种工程化的工具来满足这种软件开发的要求。它要求软件行业能够像搭积木一样的组装出任意复杂度和规模的软件出来，这就是“组件化思想”（或者说模块化思想）。
OOP是组件化思想的一种体现，但并非唯一一种体现，譬如还有MFC，SOA，微服务……等。不用管名词是什么，粒度是什么，其实他们本质都是一个东西——分而治之。这种思想得以实施的一个前提是复杂度内部的耦合度和抽象。
组件化思想的目的是向上层屏蔽复杂性。所以这就意味着它的前提必须是基于耦合性和抽象的。如果不基于耦合性，则必须将内部错中复杂的关系暴露给上层——这是违反屏蔽复杂性目的。如果不基于抽象，而基于具体，则任何具体的变化会导致所有依赖这个组件的软件产生联动，这同样违反向上层屏蔽复杂性。
这里基于内聚性，大家都知道，都会努力做，只不过做的好不好而已。但是第二条，其实做到的并不多。面向对象编程圈同样有另外一个遗毒甚广的原则“复用”，甚至很多开发跟我说OO的精髓就是复用。代码里有点相似的东西，就考虑复用。我强调一下：复用的前提是抽象，N个业务线某几块代码是相似的，你复用了，如果不是基于抽象的复用，而只是单纯的复用，那么任意一个业务线的逻辑变化导致共有快逻辑变化的将是一个巨大的风险。这在太多的企业都是常见的，也是这个错误原则遗毒甚广的体现。 在这种情况下，复用不如面条式的代码。（可以说，现实情况下大多数情况下，应该都不如），真正能从业务模块抽象出能隔离具体，隔离变化的共有模块是非常难的。不是简单的代码复用就可以做到的。
流毒甚广的OO三原则：封装，继承，多态，为什么说他们流毒甚广呢？上面我们提到的东西，就是更基本的原则。其中只有封装是对的，继承和多态在很多情况下问题都颇多。有兴趣的可以百度下。
只有理解了程序的复杂性，和解决复杂性的手段，以及这个手段和OOP之间的关系，才算是基本了解了OOP的本质。
这里面有很多较细的情况
1，程序都是复杂性的么？
2，复杂性必须只能用OOP解决么？如过不是，什么情况下OOP合适？哪些情况其他 ？
3，OOP解决的真正有效的手段是什么？有哪些是谬误的，或者问题比较多的，如何规避？
OOP是一种结构主义。
随着计算机的普及，越来越复杂的问题，用面向过程来解决，实在是太复杂了。
通过抽象，发现现实问题领域中的结构，有助于帮助我们简化问题。OOP就应运而生。
使用OOP语言，我们就可以很方便地对问题领域的主要结构进行抽象和表达。这也是符合我们人类思维直觉的一种认知方式。
作者：张汉东
链接：https://www.zhihu.com/question/305042684/answer/692723058
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。