就和问用筷子吃饭有什么弊端一样。你可以说大部分西方人用筷子吃饭不如用勺子叉子方便。但是这个答案有意义吗？
所谓的面向对象却带来了巨大的类关系设计开销，这是不良设计导致的问题，不是OOP导致的问题。就像大部分西方人用筷子吃饭不方便，是因为他们不会用，而不是筷子有问题。
真心鄙视一些答案。随便看了看，例如： 1. OOP导致性能问题。 2. OOP导致不良设计。
谁同意以上陈述，我只能呵呵～。这些OOP的弊端吗？这是too young too simple的问题。
软件工程中最重要工作就是管理复杂度，没有之一。OOP是软件工程实践中总结出的范式，可以说是一种指导方针，其本质目的是管理复杂度。 OOP不等于C++,更不是等于class. C++, class只是OOP其中一种实现方式而已。Win32 API也是OOP的，见过class关键字吗？nginx也是OOP, 但是用的C语言。Javascript也是OOP的，有class关键字吗？派生，继承只是语法，扩展(Extend)和实现(Implement)才是真正的目的。搞不清楚目的乱用继承是人的问题，不是OOP的问题。
错误的OO 设计之违背Solid, TellDontAsk, CompositionOverInheritance三原则 OO 一方面是一个过载的概念（包含了很多广义的最佳实践），另一方面 OO 又被很多误解所包围。从我个人经历的角度，这些地方值得注意。
- OO 是一个与时俱进的概念，我们不能绝对的讨论最早提出 OO 理论的人所谈论的那个 OO。我们还要讨论后来对 OO 阐述的不同角度，或者说 OO 的不同流派。我比较支持 Ward Cunningham 流派，他的流派也就是后来的 Martin Fowler, Kent Beck, Robert C Martin 所阐述的那个 OO。因为这个流派更注重代码和人的关系（后来也就产生了 Agile，也是这堆人），重构和模式这种长期关注代码设计的实践在这种 OO 流派中非常流行。我个人觉得咱们大学时候学的那些 OOP 的东西太抽象，给理解增加了难度。模式还有重构让我们重新回归到实践上来，具象的讨论 OO。
- 编程中的一个难题是状态的维护。我们常见的 OO，面向过程，声明式编程（包括了函数式编程）这些流派都在研究如何让状态可控。现在比较流行的 OO 和函数式编程都有成熟的模式去管理状态。而且殊路同归的是用面相函数的方式组合出 OO 的代码是完全可行的。有时我觉得无非是自底向上和自顶向下分析的不同而已。都是一个抽象的过程，我们都希望减少 side effects。
- SOLID (object-oriented design) 原则，TellDontAsk 原则，还有 Composition over inheritance 。因为这个是大部分满口 OOP 的人天天都在做错的事情，你有没有拿这些基本的观点去衡量你的 OO 设计是否优秀？每个支持 OOP 的语言有自己的取舍，但是你会发现这个语言里面好的代码会遵从这个原则。类、接口、继承是个坑，我们不能讨论哪个语言在这方面设计的完美。但是我们可以问问自己你是否错误的使用了继承实现代码复用？是否可以使用组合来实现复用？对象之间是否只有协作，而没有依赖互相的细节（Tell Don't Ask）？如果你讲了这些原则，那么对方应该知道你是一个知道 know why 的人，而不是仅限 know what and how。一上来就说 OO 三原则是封装，继承，多态的，我看这也就是停留在大学生的水平了。
- OOP 是一个方法论，不能过于务虚。最好的方式就是根据一个具体的业务问题让不同的程序员写自己的抽象（分解为对象），然后大家一起讨论一下到底谁的抽象更好。时间会说明问题，一个好的 OO 抽象可以让你的代码长期的容易维护。而且一个问题显然有很多好的抽象，常开开眼是很好的。推荐阅读 DHH 笔伐 hexagonal design 的这个线索 https://gist.github.com/dhh/4849a20d2ba89b34b201 ，里面阐述了一个非常复杂但是优雅的 OO 设计，但是所有的人都承认这个设计是很二的。这种辩证的讨论一个具体问题的过程非常锻炼你对代码设计的 critical thinking。
- 请不要陷入一些常见的 troll：不要讨论语言的 OOP 具体实现的细节的优劣；不要选择否定 OOP 的某个细节就否定 OOP 的思路，你的目的应该是博取所长；不要把性能搬出来，这是个驴唇不对马嘴的东西，因为每个方法论都有它的问题域（我还不相信确定性呢）；
- OO 作为方法论，他的核心目标：代码可复用，代码容易维护（容易理解，容易维护，容易改变）。
