OOP什么时候更适合？

Question

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

Answer 1

没有严格的规则。当你更善于解决问题和思考OO心态时，用OOP可以更好地解决问题。面向对象只是尝试使计算成为解决问题的更好工具的另一个工具。

但是，它可以允许更好的代码重用，并且还可以导致更整洁的代码。但这些高度赞扬的品质往往具有很小的实际价值。将OO技术应用于现有的功能应用程序可能会导致很多问题。技能在于学习许多不同的技术并应用最适合手头的问题。

OO经常被引用为类似Nirvana的软件开发解决方案，但是有很多时候不适合应用于手头的问题。它经常会导致问题的过度设计，以达到完美的解决方案，而这通常是没有必要的。

本质上，OOP并不是面向对象的编程，而是将面向对象思维映射到能够支持OO技术的编程语言。 OO技术可以由非本质OO语言支持，并且有一些技术可以在函数语言中使用以利用这些优势。

作为一个例子，我现在已经开发了大约20年的OO软件，所以我倾向于在解决问题时用OO术语来思考，无论我写的语言如何。目前我正在使用Perl 5.6实现多态性，本身并不支持它。我选择这样做，因为它会使代码的维护和扩展成为一个简单的配置任务，而不是开发问题。

不确定这是否清楚。在OO法庭上有些人很难，而且在功能法庭上有些人很难。然后有些人尝试过这两种方法，并试图从每个方面都做到最好。两者都不是完美的，但两者都有一些非常好的特性，无论语言是什么都可以使用。

如果您正在尝试学习OOP，请不要只关注OOP，而是尝试将面向对象分析和一般OO原则应用于问题解决方案的整个范围。

Answer 2

我是一个老计时器，但也已经编程了很长时间的OOP。我个人反对使用OOP来使用它。我更喜欢对象具有存在的特定原因，他们模拟具体的东西，并且它们是有意义的。

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

我的底线是，如果它作为对象有意义，则将其编程为对象，只要您考虑对象模型实现的性能/资源影响。

Answer 3

我认为，当您对这些状态的状态和相关操作进行建模时，它最适合。我猜这有点模糊，但我不确定这里有一个完美的答案。

关于OOP的是它可以让你封装和抽象数据和信息，这对于构建一个大型系统来说是一个真正的好处。你可以对其他范例做同样的事情，但看起来OOP在这个类别中特别有用。

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

Answer 4

我卖给了OOP。

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

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

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

Answer 5

有5个标准是否应该支持面向对象，基于对象，功能或程序代码。请记住，所有这些样式都适用于所有语言，它们是样式。所有这些都是以“我应该在这种情况下支持OO吗？”的风格写成的。

系统非常复杂，具有超过约9k的LOC（只是任意级别）。 - 随着系统变得越来越复杂，封装复杂性所带来的好处相当多。使用OO，与其他技术相反，您倾向于封装越来越多的复杂性，这在此级别非常有价值。在此之前，应该优先考虑基于对象或程序。 （这并不是在提倡一种特定的语言。OO C在我的脑海中比OO C ++更符合这些特征，这种语言因泄漏的抽象而具有臭名昭着的声誉，并且能够以1个平庸/顽固的程序员为商店吃饭。午餐）。

您的代码不是对数据的操作（即基于数据库或基于数学/分析）。基于数据库的代码通常更容易通过程序样式表示。基于分析的代码通常更容易用函数式表示。

你的模型是模拟某些东西（OO擅长模拟）。

你正在做一些基于对象的OO子类型调度是有价值的事情（也就是说，你需要向某个类型和各种子类型的所有对象发送消息，并得到一个适当但不同的反应他们）。

您的应用不是多线程的，尤其是在非工作者任务方法类型的代码库中。在多线程并且需要不同线程来执行不同任务的程序中，OO是非常有问题的。如果你的程序是由一个或两个主线程和许多工作线程做同样的事情构成的，那么OO程序的混乱控制流程更容易处理，因为所有工作线程都会被触摸隔离，并且可以被认为是代码的整体部分。实际上考虑任何其他范例。功能优于多线程（缺乏副作用是一个巨大的好处），基于对象的编程可以为您提供一些OO的封装，但是在代码库的关键部分有更多可跟踪的过程代码。程序当然也在这个舞台上表现出色。

Answer 6

OO不太好的一些地方是你在处理像SQL一样的“数据集”。 OO倾向于使基于集合的操作更加困难，因为它并非真正设计为最佳地采用两组的交集或两组的超集。

此外，有时候功能方法会更有意义，例如这个例子来自MSDN：

  

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

Answer 7

我觉得从“事物”的角度来思考一个特定问题是有帮助的。

如果问题可以被认为是有一个或多个“事物”，那么每个“事物”都有许多涉及其状态的属性或信息，以及可以在其上执行的许多操作 - 那么OOP可能是要走的路！

Answer 8

学习面向对象编程的关键是学习设计模式。通过了解设计模式，您可以在需要课程时以及何时不需要课程时更好地看到。与编程中使用的任何其他内容一样，OOP语言的类和其他功能的使用取决于您的设计和要求。与算法类似设计模式是更高层次的概念。

设计模式与传统编程语言的算法类似。设计模式告诉您如何创建和组合对象以执行一些有用的任务。与最佳算法一样，最佳设计模式通常足以应用于各种常见问题。

Answer 9

在我看来，这是一个关于你作为一个人的问题。某些人在功能方面认为更好，而其他人更喜欢类和对象。我会说当OOP与世界的内部（主观）心理模型相匹配时，OOP更适合。

Answer 10

面向对象的代码和过程代码具有不同的可扩展性点。面向对象的解决方案使得在不修改现有函数的情况下更容易添加新类（参见开放 - 封闭原则），而过程代码允许您在不修改现有数据结构的情况下添加函数。根据预期的变化类型，系统的不同部分通常需要不同的方法。

Answer 11

OO允许将与对象相关的逻辑放置在单个位置（类或对象）中，以便可以将其解耦并更易于调试和维护。

我所观察到的是，每个应用程序都是OO和过程代码的组合，其中过程代码是将所有对象绑定在一起的粘合剂（至少是主函数中的代码）。您将程序代码转换为OO越多，维护代码就越容易。

Answer 12

为什么OOP用于编程：

1. 它的灵活性 - 在使用实施方面，OOP非常灵活。
2. 它可以减少超过99.9％的源代码 - 听起来我可能过于夸张，但确实如此。
3. 实现安全性要容易得多 - 我们都知道安全性是Web开发的关键要求之一。使用OOP可以简化Web项目中的安全实现。
4. 它使编码更有条理 - 我们都知道清洁程序是一种清洁编码。使用OOP而不是程序使事情更加有条理和系统化（显然）。
5. 它可以帮助您的团队轻松地相互合作 - 我知道您有些人经历过团队项目，而且有些人知道拥有相同的方法，实现，算法等等很重要。

Answer 13

它取决于问题：OOP范例在设计分布式系统或框架时很有用，在用户的操作过程中有很多实体（例如：Web应用程序）。

但如果你有数学问题，你会更喜欢功能语言（LISP）;对于性能关键系统，您将使用ADA或C等等。

语言OOP很有用，因为它在程序运行中也可能使用垃圾收集器（自动使用内存）：你在C中编程很多时候必须手动调试并纠正内存问题。

Answer 14

当你有东西时，OOP很有用。套接字，按钮，文件。如果你在er中结束一个类，它几乎总是一个假装成一个类的函数。 TestRunner很可能应该是一个运行测试的函数（可能还有运行测试）。

Answer 15

就我个人而言，我认为OOP实际上是任何大型应用程序的必需品。我无法想象在不使用OOP的情况下拥有超过10万行代码的程序，这将是一个维护和设计的噩梦。

Answer 16

我告诉你OOP是坏事。

当架构师编写非常复杂的，未记录的OOP代码时。离开项目一半。他在各种项目中使用的许多常用代码都缺少代码。感谢上帝为.NET Reflector。

组织没有运行Visual Source Safe或Subversion。

我很抱歉。登录的2页代码相当荒谬，即使它是可爱的OOPed ....