什么时候OOP更适合？

自从我开始研究面向对象编程以来，我经常阅读文章/博客，说函数更好，或者不是所有的问题都应该建模为对象。从您的个人编程经历来看，您认为OOP什么时候能更好地解决问题？

我认为，当您对与状态相关联的行为进行建模时，它最适合。我想这有点模糊，但我不确定这里是否有一个完美的答案

OOP的好处在于它可以让你封装和抽象数据和信息，这对于构建一个大型系统来说是一个真正的好处。您可以对其他范例执行相同的操作，但OOP似乎在这方面特别有用

这也取决于你使用的语言。如果它是一种具有丰富OOP支持的语言，那么您可能应该利用它。如果没有，那么您可能需要找到其他机制来帮助将问题分解为更小、易于测试的部分。

我被OOP说服了

任何时候你可以为一个问题定义一个概念，它可能会被包装在一个对象中

OOP的问题是，有些人过度使用了它，使他们的代码更难理解。如果您对在对象中放置的内容以及在服务（静态类）中放置的内容非常谨慎，那么您将从使用对象中获益

---

只是不要把不属于某个对象的东西放在对象中，因为你需要你的对象做一些你最初没有想到的新东西，重构并找到添加该功能的最佳方法。

没有硬性规定。当你能更好地用面向对象的思维解决问题和思考问题时，OOP能更好地解决问题。面向对象只是另一种工具，它是通过努力使计算成为解决问题的更好工具而产生的

然而，它可以允许更好的代码重用，也可以导致更整洁的代码。但通常，这些受到高度赞扬的品质实际上没有什么实际价值。将OO技术应用于现有的功能应用程序可能会导致很多问题。技巧在于学习许多不同的技巧，并将最适合的方法应用于手头的问题

OO经常被引用为软件开发的涅磐式解决方案，但是有很多时候它不适合应用于手头的问题。这常常会导致对问题进行过度设计，以获得完美的解决方案，而实际上这并不是必须的

实际上，OOP并不是真正的面向对象编程，而是将面向对象的思想映射到能够支持OO技术的编程语言。OO技术可以由非固有OO的语言支持，并且可以在函数式语言中使用一些技术来利用这些好处

举个例子，我已经开发OO软件20年了，所以我在解决问题时倾向于用OO的术语思考，而不管我用什么语言写。目前，我正在使用Perl5.6实现多态性，Perl5.6本机不支持多态性。我选择这样做是因为它将使代码的维护和扩展成为一项简单的配置任务，而不是开发问题

不确定这是否清楚。在OO法庭上有一些人很强硬，在功能法庭上也有一些人很强硬。还有一些人尝试了这两种方法，并试图从中吸取最好的。两者都不是完美的，但都有一些非常好的特点，你可以利用，无论什么语言

---

如果你想学习OOP，不要只关注OOP，而要尝试将面向对象分析和一般OO原则应用到整个问题解决方案中。

OO不太好的地方是处理SQL中的“数据集”。OO倾向于使基于集合的操作变得更加困难，因为它并不是真正设计为以最佳方式获取两个集合的交集或两个集合的超集

此外，有时功能性方法更有意义，例如以下示例：

例如，考虑编写一个程序将XML文档转换为不同形式的数据。虽然当然可以编写一个C#程序，通过XML文档进行解析，并应用各种if语句来确定在文档中的不同点要采取的操作，但一种可以说是更好的方法是将转换编写为可扩展样式表语言转换（XSLT）程序。毫不奇怪，XSLT内部有大量的功能主义

---

我发现用“事物”来思考一个给定的问题是有帮助的

---

如果问题可以被认为是有一个或多个“东西”，其中每个“东西”都有许多属性或信息块，这些属性或信息块涉及到它的状态，并且可以对其执行许多操作，那么OOP可能是一种方法

我是个老家伙，但也编写OOP程序很久了。我个人反对仅仅为了使用OOP而使用OOP。我更喜欢对象有特定的存在理由，它们为具体的东西建模，并且它们是有意义的

我遇到的问题是，很多新开发人员对他们所创建的代码所消耗的资源没有概念。在处理大量数据和访问数据库时，“完美”对象模型可能是性能和资源方面最糟糕的事情

---

我的底线是如果它作为一个对象是有意义的，然后把它编程为一个对象，只要考虑到你的对象模型的实现的性能/资源影响。

< P>学习面向对象编程的关键是学习设计模式。通过学习设计模式，您可以更好地了解何时需要类，以及w