这个问题有点启发：对于什么常见的问题，函数式编程不太适合？-但是我一直想问这个问题，但是太害怕问了。
我一直都在...好吧，实际上我们一生都可以称之为工程软件开发，而且在所有时间里，尽管OO一直都存在（嗯，大部分时间），但我从未使用过“它的方式”，也不学习这种范式。我们一直使用相当简单的程序结构，例程/函数/模块，尽管它与当今管理这些程序的最佳实践（程序的最大LOC约为300k，没有太大的问题）相反，但从未证明是困难的，更不用说不可能了。
因此，我想问你，对于哪种面向对象范例不是一个好的选择会有什么问题？与程序编程相比？
Answers:
面向对象编程是过程编程。正如罗伯特·哈维（Robert Harvey）在评论中提到的，使面向对象的事物是面向对象以一种特定的方式抽象数据（即：将在该结构上操作的功能与该结构捆绑在一起）。
William Cook很好地解释了对象和抽象数据类型之间的区别。
因此，冒听起来容易的风险，我想说当您需要轻松扩展对数据执行的操作（数量）并且您不需要采用各种实现方式时，对象就不太适合数据。话虽如此，您可以做一些事情来使两者更紧密地联系在一起。
OO的主要价值在于，它提供了系统组件之间的去耦功能，从而使编写DRY代码和适应设计中计划的特定更改类型变得更加容易。代价是它增加了间接层，这会使代码更难以推理，效率更低，更难以以意料之外的方式修改（设计脱钩所无法提供的方式）。因此，对于不需要子程序提供的去耦的任何子问题，这都是浪费时间。具体地说，如果您可以轻松地编写没有它的DRY代码，并且不期望任何特定的需求更改会受益于OO提供的强大去耦功能，那将是浪费时间。
并发：锁定机制似乎有点问题；只有一些非常优秀的开发人员可以在项目的线程部分工作
扩展：不知道当前的面向对象语言有多可扩展。只知道Java是不好的。因此，必须将DSL（特定领域语言）实现为框架。另一方面，Clojure（具有功能）具有宏。
我认为，当构建通过Web API（其余，xmlprc，普通curl / wget）组合其他系统的系统时，可以编写OO包装器，但这显然只是一个方便。如果要使用的Web服务很简单，仅需一行或两行，那么OO太多了。另一方面，如果您最终不得不包装一个复杂的Web api（例如Amazon AWS），那么拥有一个包装器库（例如python中的boto for AWS）就很好了。
有什么想法吗？
面向对象的编程可以用来为您的领域建模。这些类可用于表示域模型内的实体，聚合，协作，服务的状态和行为。此外，对象之间的方法调用和协议可以对实体之间的动态关系进行建模。
我发现这是一种生成DRY模型的有用方法，该模型可以与技术问题（例如，使用数据库，消息队列或实际上它是一个Web应用程序）。关于该主题的一本好书是域驱动设计
这里要注意的重要一点是，我上面提到的“实体”不必映射到现实世界的对象上！它们可以代表应用程序域的抽象部分。
因此，如果这就是面向对象编程所擅长的；什么不擅长？好吧，任何领域模型不能很好地表达为对象的事物。例如，一些数学（统计，逻辑等）或技术（例如编译器）程序可以用不同的样式更好地表达。我发现，对于业务工作流应用程序，OO和自定义DSL技术的组合在允许我们对业务流程中发生的各种关系和事件进行建模方面非常有效。对于程序验证和自动校对检查，通常使用一种功能方法，因为它的纯功能允许更直接的数学推理。