为什么OOP很难？ [关闭]

#1 楼

我个人发现OOP的机制相当容易掌握。对我来说最困难的部分是它的“为什么”。当我第一次接触它时，它似乎是寻找问题的解决方案。以下是我认为大多数人都很难做到的几个原因：


恕我直言，从一开始就讲授面向对象是一个可怕的想法。程序编码不是“坏习惯”，它是某些工作的正确工具。无论如何，OO程序中的各个方法往往看起来很程序化。此外，在足够好地学习过程编程以使它的局限性变得显而易见之前，面向对象的学习对学生似乎不是很有用。
在真正掌握面向对象之前，您需要了解数据结构和后期绑定/的基础知识。高阶函数。如果您甚至不了解构造数据的概念，而不是仅仅使用基元并传递高阶函数，就很难理解多态性（基本上是传递指向数据的指针和一堆对数据进行操作的函数）函数的指针。
设计模式应该作为面向对象的基础，而不是更高级的。设计模式可以帮助您从树上看森林，并给出相对具体的示例，以了解OO可以简化实际问题，并且您最终将想要学习它们。此外，一旦您真正了解了面向对象，大多数设计模式在事后都会变得显而易见。

#2 楼

我认为有些因素尚未提及。

首先，至少在“纯OOP”（例如Smalltalk）中，凡事都是对象，您必须将思维转变为一种不自然的配置，以想到一个数字（仅适用于一个）例如）作为一个智能对象，而不仅仅是一个值-因为实际上，21（例如）实际上只是一个值。一方面，当您被告知OOP的一大优势是更紧密地建模现实时，这变得尤其成问题，但您首先要从看起来像LSD启发的视图中看到很多东西，甚至是LSD的最基本和最明显的部分。

其次，OOP中的继承也不是很遵循大多数人的思维模式。对于大多数人而言，最明确的分类方法没有接近创建有效的类层次结构所必需的绝对规则的任何地方。特别是，创建从另一个class D继承的class B意味着class D的对象绝对共享，肯定具有class B的所有特征。 class D可以添加自己的新特性和不同特性，但是class B的所有特性必须保持不变。

相反，当人们从心理上对事物进行分类时，它们通常遵循更为宽松的模型。例如，如果一个人对构成一类对象的规则制定了一些规则，那么只要遵循了足够多的其他规则，几乎任何一条规则都可以被打破，这是很典型的。即使是一些无法真正打破的规则，也几乎总会被“拉伸”。

仅举例来说，将“汽车”视为一类。很容易看出，大多数人认为“汽车”的绝大多数都有四个轮子。但是，大多数人都看过（至少是照片）只有三个轮子的汽车。我们中的一些年龄合适的人还记得80年代初（或大约20年代）有六个轮子的赛车-依此类推。这基本上给了我们三个选择：


不要断言汽车有多少个轮子-但这会导致隐含的假设，即它永远是4 ，以及可能会破译另一个数字的代码。
断言所有汽车都有四个车轮，即使我们知道它们确实是四个车轮，也要将它们归类为“非汽车”。
设计该类以允许轮数的变化，以防万一，即使很有可能永远也不需要，不会使用或经过适当的测试。

关于OOP的教学通常侧重于建立巨大的分类法-例如，这将是地球上所有已知生命或此秩序上某个事物的巨大层次结构。这带来了两个问题：首先，也是最重要的是，它趋向于导致许多人专注于与眼前的问题完全无关的大量信息。在某一时刻，我看到了关于如何为犬种建模的漫长讨论，以及（例如）“迷你贵宾犬”是否应该继承“全尺寸贵宾犬”，反之亦然，或者是否应该有一个抽象的基础“贵宾犬”类，其中“全尺寸贵宾犬”和“微型贵宾犬”都继承自它。他们似乎都忽略了该应用程序应该用于跟踪狗的许可证，并且出于手头的目的，只需要一个名为“品种”（或该顺序的名称）的字段就足够了。完全建立品种之间关系的模型。

其次，也是非常重要的一点，它导致关注于项目的特征，而不关注于对当前任务很重要的特征。它导致对事物进行建模，真正需要的地方（大部分时间）是构建满足我们需求的最简单模型，并使用抽象来适应必要的子类以适应我们已经构建的抽象。 br />
最后，我再说一遍：多年来，我们正在缓慢地遵循数据库所采用的相同路径。早期的数据库遵循分层模型。除了只关注数据之外，这是单一继承。在很短的时间内，一些数据库遵循了网络模型-本质上与多重继承相同（从这个角度来看，多个接口与多个基类并没有什么不同，足以引起注意或关注）。

但是，很久以前，数据库很大程度上都集中在关系模型上（尽管它们不是SQL，但在这种抽象级别上，当前的“ NoSQL”数据库也是关系数据库）。关系模型的优点是众所周知的，因此在这里我不再赘述。我只是注意到，我们在编程中与关系模型最接近的类比是泛型编程（很抱歉，尽管名称如此，但Java泛型实际上并没有真正的资格，尽管它们在开发过程中迈出了很小的一步。正确的方向）。

#3 楼

OOP要求具有抽象思考的能力；很少有人甚至专业程序员真正拥有的礼物/诅咒。

#4 楼

我想您可以这样总结基本的困难：

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

当然，人们可以习惯将“ left”映射为270，是的，说“ Car “转弯”而不是“转弯汽车”并不是一个巨大的飞跃。但是，要很好地处理这些对象并创建它们，您必须颠倒通常的思维方式。

我们不是在操纵对象，而是在告诉对象实际独立地做事。可能不再感到困难，但是告诉窗口自己打开听起来很奇怪。不习惯这种思维方式的人们必须不断地与这种怪异作斗争，直到最终它以某种方式变得自然。

#5 楼

对于大多数人来说，任何范例都需要一定的“边缘”推动才能掌握。根据定义，这是一种新的思维方式，因此它需要一定程度的放开旧观念，并需要一定程度的完全掌握新观念为何有用的原因。

我认为很多问题是，用于教授计算机编程的方法通常很差。 OOP现在是如此普遍，以至于它不那么引人注目，但您仍然在函数式编程中经常看到它：


重要的概念隐藏在奇数名称后面（FP：什么是单子？OOP：为什么他们有时会称它们为函数，有时又称其为方法吗？）
奇数的概念是用隐喻来解释的，而不是根据它们的实际作用，为什么使用它们或为什么有人曾想使用它们来解释（FP ：一个monad是一个太空服，它包装了一些代码OOP：一个对象就像鸭子，它可以发出声音，走路并从Animal继承）
好东西因人而异，因此并不完全清楚什么将成为任何学生的转折点，并且通常老师甚至不记得了。 （FP：哦，monad使您可以在类型本身中隐藏某些东西并继续下去，而不必每次都明确地写出正在发生的事情。OOP：哦，对象使您可以使用该数据保留某种数据的功能。）

最糟糕的是，正如问题所表明的那样，有些人会立即认清为什么这个概念很好，而有些人则不会。这实际上取决于转折点是什么。对我而言，掌握对象存储数据和该数据的方法是关键，在此之后，其他所有内容都可以自然地扩展。然后，我后来跳了起来，就像意识到从对象进行方法调用与以该对象作为第一个参数进行静态调用非常相似。

稍后会有所帮助，以帮助增进理解，但这是使一个人摆脱“ OOP毫无意义，为什么人们这样做的原因”的最初原因。到“ OOP是最好的，人们为什么还要做其他事情？”

#6 楼

因为OOP的基本解释与它在现场的用法几乎没有关系。大多数用于教学的程序都尝试使用物理模型，例如“以汽车为对象，以车轮为对象，以及门和变速器……”，但是在一些模糊的模拟编程案例之外，对象通常用于表示非物理概念或引入间接。其效果是使人们以错误的方式直观地理解它。

从设计模式中进行教学是描述OOP的一种更好的方法，因为它向程序员展示了如何使用这些方法可以有效地解决一些实际的建模问题。对象，而不是抽象地描述它。

#7 楼

我在大多数情况下不同意dsimcha的回答：


从一开始教OO本身并不是一个坏主意，教学过程语言也不是一个坏主意。重要的是，我们要教人们写清晰，简洁，有凝聚力的代码，而不管OO或过程如何。
好的OO程序中的各个方法根本不会成为过程性的。随着OO语言的发展（阅读C＃，因为除C ++以外，我才知道这是唯一的其他OO语言）以及它们的语法越来越复杂（lambda，LINQ到对象等），这种情况变得越来越真实。程序语言中的OO方法和过程之间唯一的相似之处是每种方法的线性本质，我怀疑这很快就会改变。
如果不了解数据结构，您也无法掌握一种程序语言。指针概念对过程语言和对OO语言一样重要。例如，通过引用传递参数（这在过程语言中很常见）要求您理解指针，就像学习任何OO语言一样。
我不认为应该在OO早期就教授设计模式。根本不编程，因为它们根本不是面向对象编程的基础。在不了解设计模式的情况下，绝对可以成为一名优秀的面向对象程序员。实际上，一个人甚至可以使用众所周知的设计模式，甚至不知道它们以适当的名称记录下来，也没有写过关于它们的书。应该从根本上讲授设计原则，例如单一职责，开放关闭和接口隔离。不幸的是，如今许多认为自己是面向对象程序员的人要么不熟悉这个基本概念，要么只是选择忽略它，这就是为什么我们那里有那么多垃圾OO代码的原因。只有对这些原则和其他原则有透彻的了解之后，才能介绍设计模式。

要回答原始发布者的问题，是的，OO是比过程编程更难理解的概念。这是因为我们没有考虑现实生活对象的属性和方法。例如，人的大脑并不容易将“ TurnOn”视为电视的一种方法，而是将其视为人类打开电视的功能。类似地，对于人类大脑来说，多态性是一个陌生的概念，通常只通过一个“面孔”就能看到每个现实对象。再次继承对我们的大脑来说不是自然的。仅仅因为我是一名开发人员，并不意味着我的儿子会成为一名开发人员。一般来说，需要对人的大脑进行培训以学习OO，而过程语言则更自然。

#8 楼

我认为许多程序员在开始时就很难进行前期设计和规划。即使有人为您完成所有设计，仍然有可能脱离OOP原则。如果我使用一堆意大利面条代码并将其转储到一个类中，那真的是OOP吗？某些不了解OOP的人仍然可以使用Java进行编程。另外，不要将理解困难与不愿意遵循某种方法或不同意它混淆。

#9 楼

您应该阅读Objects Never？好吧，几乎没有。 Mordechai Ben-Ari（需要ACM成员资格）认为OOP如此困难，因为它不是对任何事物建模的自然范式。 （尽管我对此文章有所保留，因为尚不清楚他认为程序是使用OOP范式而不是使用OO语言编写的程序范式，他认为程序需要满足什么条件。）

#10 楼

面向对象编程本身并不难。

做起来很难。在代码之间放置剪切的位置，以便可以轻松地将内容移动到通用基础对象，并在以后进行扩展？如何使您的代码可被其他人使用（扩展类，包装代理，覆盖方法），而无需跳过箍。

那是很难的部分，如果做得对，可能会非常优雅，如果做得不好，会变得非常笨拙。我的个人经验是，在所有情况下都需要进行大量练习，以使您这次做得足够好。

#11 楼

我只是看了理查德·费曼（Richard Feynman）的一段视频，该视频讨论了人们在思考时可能实际上完全不同的方法。我的意思是完全不同。

当我进行高级设计时，我碰巧可视化对象，我可以看到它们，看到它们的界面，以及信息需要穿越的路径。

我也很难记住细节，并发现OO是一种组织上的帮助-与浏览松散组织的子例程列表相比，查找功能要容易得多。

对于我OO是一个很大的好处，但是如果您不以相同的方式进行可视化或不执行高级体系结构，则可能毫无意义且令人讨厌。

#12 楼

在介绍给OO之前，我已经做了相当多的GW-Basic和Turbo Pascal编程，所以最初它是DID负责的事情。

不知道这是否会对别人产生影响，但对我来说就像这样：我对编程的思考过程纯粹是程序性的。如：“发生某事，然后发生某事”，等等。我从不认为变量和数据只是程序流程中短暂的参与者。编程是“行动的流程”。

我认为不容易掌握（就像现在看来对我来说很愚蠢）的想法是，数据/变量实际上真正重要。比在节目“流程”中只是转瞬即逝的演员更深刻的意义。或换种说法：我一直试图通过发生的事情而不是通过什么来理解它，这是掌握它的真正关键。

#13 楼

我认为这并不难理解，但是可能很多程序员对这个概念感到陌生，它们来自过程语言。

从我所见/读到的很多人看来（至少在论坛中）从OOP寻找“结果”。如果您是不回头修改程序代码的过程程序员，那么可能很难理解它的好处。

此外，如果人们不满意，那么那里会有很多糟糕的OOP。阅读/看到这样就很容易理解为什么他们可能会感到困难。

IMO，您需要等到它“单击”或由真正有知识的人教给我，我才认为您会赶。

#14 楼

我认为许多人都难以理解OOP的原因是因为这些工具并不能真正促进它。

当今的计算机语言是计算机中正在发生的事情的抽象。

OOP是一种表示抽象的抽象方法。

因此，我们正在使用抽象来构建具有抽象的抽象。除此之外，我们提取的内容通常是非常复杂的物理/社交交互，而且，难怪。

#15 楼

我实际上有一个名为“面向对象编程的斗争”的博客，它源于我在学习它方面的一些挣扎。我认为我很难理解，因为我花了很多时间使用过程编程，而且我很难理解这个想法，即对象可以由一组属性和行为表示（我习惯于只是变量和方法的集合）。

另外，有许多使语言面向对象的概念-继承，接口，多态性，组成等。在实际编写代码之前，确实有很多知识要学习。有效地并且以面向对象的方式，而使用过程编程，这仅仅是了解诸如变量的内存分配以及对其他方法的入口点调用之类的问题。

#16 楼

动机。当您不了解原因以及当您无法看清所做的事情并弄清自己是否做对了时，很难学习一些东西。

需要的是使用OO做有用的事情。我建议浏览一本有关设计模式的书，并提出一本显然有用并且与OO兼容的书。 （我曾经尝试过使用Strategy。像Flyweight或Singleton之类的东西会是错误的选择，因为它们通常是使用对象的方式，而不是使用对象来完成任务。）

#17 楼

我认为这取决于年龄（年龄代表经验），更重要的是兴趣。如果您“年轻”（例如，绿色），并且从未想过其他任何方法，那么这似乎很简单。另一方面，如果您认为这是您所见过的最酷的东西-28岁时在我身上发生的事情-很容易gr。

另一方面，如果您认为，就像我的许多Java学生所做的那样，“我们为什么要学习它，这只是一时的风尚”，几乎是不可能学习的。大多数技术都是如此。

#18 楼

不管选择哪种范例（OOP，功能等），要编写计算机程序，都需要知道程序将执行哪些步骤。

定义过程的自然方法是编写降低其步骤，对于较大的任务，可以将任务分解为较小的步骤。这是程序性的方式，这是计算机的工作方式，这是您逐步检查清单的方式。

OOP是另一种思维方式。不用考虑需要逐步完成的任务清单，而是考虑对象，对象的能力和关系。因此，您将编写许多对象，小的方法，并且程序将神奇地工作。要实现这一目标，您需要改变主意...

，这就是为什么OOP很难实现的原因。由于所有事物都是一个对象，所以他们要做的就是要求其他对象做某事，而这些其他对象基本上就是做某事。因此，OOP程序中的控件可以在对象之间疯狂地来回跳转。

#19 楼

作为目前正在学习编程并且在这一领域有一些问题的人，我认为这个概念的具体实现并不难理解。我之所以这样说，是因为我有了OOP的想法，并且已经在PHP中使用了大约一年，但是当我转向C＃并查看其他程序员对对象的用法时，我发现很多人这样做的方式我只是不明白。正是由于这一点，我才得以更好地理解OOP的原理。

当然，我意识到这个问题很可能是我缺乏原生OOP的经验语言，随着时间的流逝，我将发现利用对象的新方法，这些新对象对于新程序员来说就像我目前所经历的一样不清楚。杰里·科芬（Jerry Coffin）谈到了这几次，特别是在他的评论中：


一方面告诉您
OOP的一大优势在于建模，这尤其成问题更接近现实，但您首先要从看起来像LSD灵感的现实世界开始，
甚至是现实中最基本，最明显的部分。


我发现这很准确，因为当我看到某人为不是真的东西创建类时，我经常会得到这样的印象-一个具体的例子使我无所适从，但是我能即时想到的最接近的例子是距离就像物体一样（下次看到会引起同样混乱的东西时，我将进行编辑）。有时，OOP似乎暂时不理会自己的规则，变得不那么直观。当对象生成对象，从封装它们的类继承等时，这种情况经常发生。

我认为对于像我这样的人，将对象的概念视为具有多个方面会有所帮助，其中之一包括在某些情况下不会像对待对象一样对待对象。诸如距离之类的东西，仅在范式上稍有变化，就可以作为一个理论对象遇到，但是却不能握在手中。我必须认为它具有一组属性，但是具有一组更为抽象的行为，例如访问其属性。我不是很确定这是我理解的关键，但似乎是我目前的研究处于领先地位。

#20 楼

在学习面向对象编程（POOP）的原理时，术语是我前进的道路。当您掌握了基本原理后，这些东西才开始逐渐成熟。就像学习新概念的所有事情都有些困难。

同意设计模式应至少与OOP平行。

#21 楼

对我而言，主要的跃迁只是了解OOP的抽象概念。现在我对编程非常陌生，现在我已经进行了一年半的编程，所以我对OOP的介绍是使用Actionscript和Processing。当我第一次学习Actionscript编码时，它不在OOP中。我学会了直接在“动作”面板中进行编码，这就是我学习编程的基本原理（变量，函数，循环等）的方式。因此，我了解到它是直接在Flash或Processing中为舞台做些事情。

当OOP出现时，我一开始就很难意识到自己可以在对象内创建方法和属性以进行使用和重用。一切都非常抽象并且难以处理，但是编程语言本身要好得多，但是首先建立这些连接需要一种信念的飞跃。

#22 楼

食谱

良好的OOP理解=良好的导师或书籍或两者兼而有之+个人兴趣+练习。

个人兴趣

根据我的个人经验，借助导师或好书或两者的正确输入，从过程编程到OOP的桥梁很重要。

实践，实践和实践

更好地了解OOP的朋友不过是练习而已。这肯定会提高您的OOP能力。

俗话说：“没有什么可以代替辛勤工作，没有成功的捷径。”

祝你好运！