什么应该是OO，什么不应该？

Question

我读过很多人说有些东西不应该以面向对象的方式写出来 - 作为一个学习来自C背景的OO风格的人，他们的意思是什么？

什么不应该是OO，为什么有些东西更适合这种设计，我们怎么知道什么时候最好做什么？

Answer 1

现实世界充满了物体。

让软件世界与现实世界相匹配是有帮助的。

“'系统实用程序'怎么样？它们只处理套接字，进程和文件系统等抽象。”他们听起来像是我的事。他们有属性和行为，他们有联系。

如果您正在寻找证明，OO 更好，则没有。没有什么比更好因为更好是一个光荣模糊的术语。任何聪明的人都可以用任何风格编写任何程序。你可以采用功能，程序，面向对象或任何你想要的东西。

我使用面部护理，因为我的脑部很小，必须学会生活在极限之内。 OO是帮助我通过编程奋斗的拐杖。如果我更聪明，更富有，更好看，我不需要帮助，我可以编写非OO程序。可悲的是，我并不聪明。如果没有类定义来分离责任和构建架构，我仍然会编写单文件“hello world”变体。

Answer 2

一个简单的经验法则是封装复杂数据和重复使用的代码，并忽略不重复的代码。这使您可以将复杂的数据结构与其操作方法结合在一起，以实现更高的可移植性和灵活性。例如，按属性类型智能排序的数据库对象列表。

OO代码也会混淆您不需要知道的内容。比如，我不需要知道我的排序算法是什么，直到它减慢我的速度，或者我已经为高性能环境编程了。

关于OO代码的另一个好处是它的多态性，你可以使用后续类型来改变动作的方式，而不需要程序知道如何或关心它。一个示例是具有多个文件列表类型的归档格式：列表中可能有一个结构（记录或结构）数组，它在列表类型之间发生变化，但是从基类继承而且知道哪个底层结构的复杂性使用消失了。在没有面向对象的情况下管理它会非常困难，坦率地说，管理 面向对象是非常困难的。

如果你不知道如何解决它们，OO和MVC不会解决你的问题，它们只会给你更强大的方法来射击自己 - 这次你可能不知道为什么。所以请记住，如果它是任何东西，OO不是“神奇的子弹”......但请记住，在正确的情况和正确的程序员的情况下，它可以成为神奇的子弹。

Answer 3

面向对象的设计就是在系统增长时管理复杂性。因此，对于较小的不太复杂的系统，或者对于您知道永远不会增长的系统来说，OO设计可能会过度。

当然问题是我们很少确定系统不会增长。

Answer 4

我同意以上（或以下？）的大部分内容，OO的存在是为了简化复杂问题和软件设计。

然而，有很多次它极度过度。我不能告诉你我希望有一个Visual Studio Unrefactor按钮的次数只是为了理解代码并将所有基类放在一个文件中以便于阅读。

Answer 5

我想不出存储过程以外的任何东西。获取Reflector的副本并使用它来查看.NET框架dll作为一个很好的学习课程。或者，市场上有大量关于C ++和OO的书籍，因为这已经有一段时间了。

Answer 6

如果您正在编写移动应用程序（至少我可以代表.NET移动版），那么您应该尝试尽可能不使用OO。尽管移动技术已经发展，但您不希望浪费系统内存，因为您将处理与抽象层，内存中的大型数据集或其他会降低速度的实体捆绑在一起。你想要尽可能简单地写东西。

Answer 7

只是一个提示：你应该将这个问题标记为“主观”，因为每个人似乎都对这样的事情有不同的看法。