29

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

4

16 回答 16

29

没有硬性规定。当您更善于解决问题并以 OO 心态思考时，使用 OOP 可以更好地解决问题。面向对象只是通过尝试使计算成为解决问题的更好工具而出现的另一种工具。

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

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

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

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

不确定这是否清楚。OO 场有硬的人，Functional 场也有硬的人。还有一些人都尝试过，并试图从每个人身上得到最好的。两者都不是完美的，但两者都有一些非常好的特性，无论使用什么语言，你都可以使用它们。

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

于 2008-08-09T12:44:59.070 回答
9

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

我对许多新开发人员的问题是，他们对自己创建的代码所消耗的资源一无所知。在处理大量数据和访问数据库时，“完美”的对象模型可能是您在性能和资源方面所能做的最糟糕的事情。

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

于 2008-09-19T12:10:09.170 回答
6

我认为当您对与状态和在这些状态上的相关动作有凝聚力的东西进行建模时，它最适合。我想这有点模糊，但我不确定这里是否有完美的答案。

OOP 的优点在于它可以让您封装和抽象数据和信息，这对于构建大型系统来说是一个真正的福音。您可以对其他范例做同样的事情，但似乎 OOP 在这个类别中特别有用。

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

于 2008-08-09T09:07:27.653 回答
6

我被卖给了 OOP。

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

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

只是不要将不属于对象的东西放入对象中，因为您需要您的对象执行您最初没有想到的新事物，重构并找到添加该功能的最佳方法。

于 2008-08-09T12:34:42.913 回答
6

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

该系统非常复杂，大约有 9k LOC（只是任意级别）。——随着系统变得越来越复杂，通过封装复杂性获得的好处会大大增加。使用 OO，与其他技术相反，您倾向于封装越来越多的复杂性，这在这个级别非常有价值。在此之前应优先考虑基于对象或程序。（这并不是在提倡一种特定的语言。在我看来， OO C 比 OO C++ 更适合这些特性，这种语言以泄漏抽象而臭名昭著，甚至可以与一个平庸/顽固的程序员一起吃午饭）。

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

您的模型是对某些事物的模拟（OO 擅长模拟）。

您正在做一些基于对象的 OO 子类型分派很有价值的事情（也就是说，您需要向特定类型和各种子类型的所有对象发送消息，并从所有对象中获得适当但不同的反应） .

您的应用程序不是多线程的，尤其是在非工作任务方法类型的代码库中。OO 在多线程程序中存在很大问题，并且需要不同的线程来执行不同的任务。如果你的程序由一个或两个主线程和许多工作线程组成，做同样的事情，OO 程序的混乱控制流更容易处理，因为所有工作线程将在它们接触的部分中被隔离，可以被认为是一个单一的代码部分。实际上考虑任何其他范式。函数式擅长多线程（没有副作用是一个巨大的好处），基于对象的编程可以给你带来一些 OO 封装的好处，但是在你的代码库的关键部分有更多可追溯的过程代码。当然，程序在这个领域也很出色。

于 2010-11-06T13:42:41.960 回答
1

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

此外，有时功能方法会更有意义，例如取自MSDN的这个示例：

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

于 2008-08-09T14:11:47.743 回答
1

我发现从“事物”的角度来思考给定的问题会有所帮助。

如果可以将问题视为具有一个或多个“事物”，其中每个“事物”具有许多属性或引用其状态的信息片段，以及可以对其执行的许多操作 - 那么 OOP可能是要走的路！

于 2008-08-09T14:17:22.817 回答
1

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

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

于 2008-09-19T12:21:05.417 回答
1

在我看来，这更像是一个关于你作为一个人的问题。某些人在功能方面思考得更好，而另一些人则更喜欢类和对象。我想说，当 OOP 与您对世界的内部（主观）心智模型相匹配时，它更适合。

于 2008-10-13T16:59:36.553 回答
1

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

于 2009-04-28T14:41:25.870 回答
1

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

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

于 2010-12-03T00:37:43.653 回答
1

为什么使用 OOP 进行编程：

  1. 它的灵活性——OOP 在使用实现方面非常灵活。
  2. 它可以将你的源代码减少 99.9% 以上——这听起来像是我过分夸大了，但确实如此。
  3. 实现安全性要容易得多——我们都知道安全性是 Web 开发的重要要求之一。使用 OOP 可以简化 Web 项目中的安全实施。
  4. 它使编码更有条理——我们都知道干净的程序就是干净的编码。使用 OOP 而不是程序化可以使事情更有条理和系统化（显然）。
  5. 它可以帮助您的团队轻松地相互合作——我知道你们中的一些人曾经/经历过团队项目，而你们中的一些人知道拥有相同的方法、实现、算法等非常重要
于 2011-11-30T10:55:34.647 回答
0

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

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

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

于 2009-02-04T15:29:08.910 回答
0

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

于 2010-10-29T13:46:25.317 回答
0

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

于 2010-11-06T16:41:04.287 回答
-1

我告诉你什么时候 OOP 不好。

当架构师编写非常复杂的、无文档的 OOP 代码时。在项目中途离开。他在各种项目中使用的许多通用代码片段都缺少代码。感谢上帝提供 .NET Reflector。

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

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

于 2010-11-22T18:26:31.477 回答