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

解决方案

回答

我认为在建模与状态紧密结合的事物以及针对这些状态的关联动作时，它最适合。我想这有点含糊，但我不确定这里是否有一个完美的答案。

关于OOP的事情是，它使我们可以封装和抽象化数据和信息，这对于构建大型系统是一个真正的福音。我们可以对其他范例执行相同的操作，但是OOP在这一类别中似乎特别有用。

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

回答

我被卖给了OOP。

只要我们可以为问题定义概念，就可以将其包装在一个对象中。

OOP的问题在于，有些人过度使用了OOP，并使他们的代码更加难以理解。如果我们对放置在对象中的内容和服务(静态类)中的内容保持谨慎，则可以从使用对象中受益。

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

回答

没有硬性规定。当我们更擅长解决问题并以OO思维方式进行思考时，使用OOP可以更好地解决问题。面向对象只是通过尝试使计算成为解决问题的更好工具而出现的另一种工具。

但是，它可以允许更好的代码重用，并且还可以使代码更整洁。但是很多时候，这些被高度赞扬的品质是不可靠的，几乎没有真正的价值。将OO技术应用于现有功能应用程序确实会引起很多问题。该技能在于学习许多不同的技术，并将最合适的方法应用于当前的问题。

OO通常被称为类似于Nirvana的软件开发解决方案，但是在很多情况下，OO不适用于当前的问题。它常常会导致过度设计问题，从而无法找到理想的解决方案，而实际上往往没有必要。

本质上，OOP并不是真正的面向对象编程，而是将面向对象的思维映射到能够支持OO技术的编程语言。 OO技术不受非OO语言的支持，并且可以在功能语言中使用某些技术来利用这些好处。

举例来说，我从事OO软件开发已有约20年的时间，因此，无论我使用哪种语言，在解决问题时我都倾向于以OO术语来思考。目前，我正在使用Perl 5.6实现多态性，而Perl 5.6本身并没有支持它。我选择这样做是因为它将使代码的维护和扩展成为简单的配置任务，而不是开发问题。

不知道这是否清楚。在OO法庭上有些人很辛苦，在功能法庭上有些人很辛苦。然后有人尝试过这两种方法，并尝试从每种方法中获得最大的收益。两者都不是完美的，但是两者都有一些非常好的特征，无论使用哪种语言，都可以利用。

如果我们想学习OOP，请不要仅仅专注于OOP，而是尝试将面向对象分析和通用OO原理用于问题解决方案的整个范围。

回答

在OO不太理想的某些地方，例如SQL，我们正在处理数据的"集合"。 OO倾向于使基于集合的运算更加困难，因为OO并不是真正设计成最佳地采用两组的交集或者两组的超集。

而且，有时功能方法更有意义，例如从MSDN提取的以下示例：

Consider, for example, writing a program to convert an XML document into a different form of data. While it would certainly be possible to write a C# program that parsed through the XML document and applied a variety of if statements to determine what actions to take at different points in the document, an arguably superior approach is to write the transformation as an eXtensible Stylesheet Language Transformation (XSLT) program. Not surprisingly, XSLT has a large streak of functionalism inside of it

回答

我发现用"事物"来思考给定的问题是有帮助的。

如果可以将问题视为具有一个或者多个"事物"，而每个"事物"都具有引用其状态的许多属性或者信息，以及可以对其执行的许多操作，则OOP为大概要走的路！

回答

我是个老计时器，但是也已经为OOP编程了很长一段时间。我个人反对使用OOP只是为了使用它。我更喜欢对象具有存在的特定原因，它们对具体的事物进行建模并且有意义。

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

我的底线是，如果我们考虑对象模型实现对性能/资源的影响，那么将其作为对象进行编程，然后将其编程为对象。

回答

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

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

回答

我认为这更多是关于我们个人的问题。某些人在功能上认为更好，而其他人则更喜欢类和对象。我要说的是，OOP与内部(主观)思维世界​​模型匹配时，它会更适合。

回答

这取决于问题：OOP范式在设计分布式系统或者框架时非常有用，该系统或者框架具有在用户操作期间存在的大量实体(例如：Web应用程序)。

但是，如果我们遇到数学问题，则更喜欢使用功能语言(LISP)。对于性能至关重要的系统，我们将使用ADA或者C等。

OOP语言很有用，因为它在程序运行时也可能会使用垃圾回收器(自动使用内存)：我们在C语言中进行编程的时间很多，因此我们必须调试并手动纠正内存问题。

回答

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

回答

有东西时，OOP很有用。套接字，按钮，文件。如果我们结束一个类，那么几乎总是一个假装为类的函数。 TestRunner很可能应该是一个运行测试的函数(并可能称为运行测试)。

回答

有5条标准是相对于基于对象的代码，功能代码还是过程代码，我们应该偏向面向对象。请记住，所有这些样式都是所有语言都可用的样式。所有这些都以"在这种情况下我应该赞成面向对象吗？"的方式编写。

该系统非常复杂，并且具有大约9k LOC(任意级别)。 -随着系统变得越来越复杂，封装复杂性所获得的好处会大大增加。与其他技术相比，使用OO往往会封装越来越多的复杂性，这在此级别上非常有价值。在此之前，应优先考虑基于对象或者过程。 (这并不是在提倡我们使用某种特定的语言。在我看来，OO C比OO C ++更适合这些功能；这种语言因泄漏抽象而臭名昭著，并且甚至可以让一位平庸/固执的程序员来商店吃饭。)

代码不是针对数据(即基于数据库或者基于数学/分析)的操作。基于数据库的代码通常更容易通过过程样式来表示。基于分析的代码通常更容易以功能样式表示。

模型是某物的模拟(OO在模拟中很出色)。

我们正在做的事情对于OO的基于对象的子类型分派来说是很有价值的(aka，我们需要向特定类型和各种子类型的所有对象发送一条消息，并从所有这些对象中获得适当但不同的响应) 。

应用程序不是多线程的，尤其是在非工作者任务方法类型的代码库中。 OO在多线程程序中需要很多问题，它们需要不同的线程来执行不同的任务。如果程序是由一个或者两个主线程构成的，并且许多工作线程都在做同一件事，那么OO程序的混乱控制流将更易于处理，因为所有工作线程都将被隔离在它们的接触范围内，可以被视为完整的代码段。实际上考虑任何其他范例。功能在多线程方面表现出色(没有副作用是一个巨大的福音)，基于对象的编程可以为我们提供一些OO封装，但是在代码库的关键部分提供了更多可跟踪的过程代码。当然，程序在此领域也很出色。

回答

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

回答

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

当架构师编写真正复杂的，未记录的OOP代码时。离开项目的一半。他在各种项目中使用的许多通用代码片段都缺少代码。感谢上帝。NETReflector。

而且该组织未运行Visual Source Safe或者Subversion。

对不起即使很可爱，两页要登录的代码也是相当荒谬的。

回答

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

我观察到的是，每个应用程序都是OO和过程代码的组合，其中过程代码是将所有对象绑定在一起的胶水(至少是主函数中的代码)。我们可以将过程代码转换为OO的次数越多，维护代码就越容易。