如果不参考实际的物理对象，如何教OO？[关闭]

14

我记得在某处读过，OO背后的原始概念是找到一种更好的体系结构，以一种保护数据状态的方式来处理多个系统之间的数据消息传递。现在这可能是一个很糟糕的措辞，但是让我想知道是否存在一种没有对象（类比，自行车，汽车，人等）的面向对象的教学方法，而是侧重于消息传递方面。如果您有文章，链接，书籍等，那将很有帮助。

object-oriented

6

我相信OO的起源是为仿真而设计的语言，它很大程度上是基于现实世界的对象。这并不意味着面向对象对于虚幻的对象不是有用的，但是您不一定必须依靠面向对象的历史来进行照明。

— 汤姆·安德森

7

为什么要在教学时避免使用熟悉的，可理解的真实对象？

— 亚当·克罗斯兰

1

不过，这是一个有趣的问题。OO是否植根于物理世界，还是不以物理世界为基础来教授OO是一个好主意，所以知道一种有效的方法来教授OO而无需参考物理世界将会变得越来越好。

— 汤姆·安德森

3

坦白说，我想再看看一些将对象用于GUI和Web应用程序的示例（例如，数据模型和视图），因为毕竟这些都是开发的精髓。“真实世界”的对象是地壳-有用的，但并不总是需要有一个良好的餐

— HorusKol

1

@HorusKol：你完全倒退了。基础的领域模型是膳食。几乎总是专注于现实世界的对象。否则，为什么要编写软件？GUI或Web演示只是服务板。有趣的是，演示文稿花费了很多精力。也许这说明了工具的原始性。

— S.Lott

4

OO的原始概念与当今的OO无关。（请参见“艾伦·凯（Alan Kay）”到底是什么意思“面向对象”的意思？）。今天的面向对象程序设计是关于创建诸如自行车，房屋和人的隐喻之类的对象的。我强烈建议您坚持使用这些隐喻，因为隐喻的目的是通过使用人们已经理解的概念来帮助人们理解。帮助他们看到相关性，然后帮助他们看到差异，然后深入了解面向对象的知识。

编辑：今天的面向对象是关于使用各种方法（函数）和属性（引用AKA变量和常量）来创建其属性和功能完全/部分描述的完全独立的对象。

— 肯尼斯
source

4

您可以谈论耦合和内聚的概念。对象应该由具有高内聚力和隐含高耦合度的属性和方法组成。它们应映射到系统正常运行所需的最精细的操作和属性。他们还应该满足保持代码尽可能小巧和直接的愿望，即在考虑维护和可扩展性的情况下进行编码。

这也可以防止“对象爆炸”，过度概括和错误的隐喻选择，这些都是常见的错误。

— 节食佛
source

1

实际回答问题而不是回答类比需要+1！

— Steven Jeuris 2011年

1

我也发现这是OO的本质。这从某种程度上解释了OO的好处，而不是它的外观。将可重用性添加到列表中，我想再次投票赞成这个答案。； p

— Steven Jeuris 2011年

2

我不会关注现实世界的对象，也不会关注消息传递。我使用的一个示例是图形中的图形，在图形中您需要具有“知道如何绘制自身”的对象。

例如，如果您使用的是C语言，而没有内置OO，则可能会发现将指针存储在数据对象内部很方便。如果这样做，那么您将陷入OOP。

我不喜欢提及艾伦·凯（Alan Kay），就好像他是摩西（Moses）分发平板电脑一样。我相信他是接受过数学和生物训练的。作为一个数学家，他可能对Lambda Calculus有所了解，这是非常抽象的，与硬件无关。在LC中，您可能会说一切都是“对象”-就像数字0和数字1是在给定参数时求值不同的对象。这很好地引导了Smalltalk。“消息”的思想是这样，我们可以避免谈论硬件。您可以说，当调用函数（或对象的方法）时，您正在向其发送消息，而当返回时，它正在向您（或您的延续）发送消息。这是描述在独立硬件上异步运行的程序之间进行通信的一种方式。没关系，但是对于普通的编程，它却变得无所适从。为了获得OOP想法的价值，您不需要否认要执行的具体任务的相关性，也不必否认正在运行的硬件的具体性。我认为从人为的类比出发讲授OOP会使人们在数据结构方面过多地考虑软件设计，导致其过分设计，导致代码膨胀和大量性能问题，我不得不花时间清理它变得足够糟糕。

— 迈克·邓拉维
source

如果您通读了我所引用的讨论，您会发现它指出Alan Kay所谓的OO与现代OO没有任何关系...这就是我引用它的原因。

— 肯尼思

@Kenneth：这是链接。我听不到AK的话是他希望他的想法成为任何人的圣经。在他看来，这是一个非常聪明的主意。他特别提到休伊特的PLANNER（我对此进行了彻底的灌输）是一种改进。这些是聪明人的好主意，无论如何也不应将它们视为圣洁的事物，而其他事物通过比较不能认为是不完美的。

— Mike Dunlavey

@Mike也许您仍在误解我的意思……我引用了我所做的讨论，以指出他的原始想法对当今的OO并没有太大用处。我绝对不会崇拜他的想法，甚至不会研究它们。

— 肯尼思

@Kenneth：我确实陷入了“热键”中，就像当我听到人们谈论真正的 OOP或AK 真正意味着什么时一样。抱歉。

— Mike Dunlavey

@迈克·艾伦·凯（Mike Alan Kay）确实说，他从微生物学培训中学到了很多灵感。特别地，他对物体的概念（并且我不记得他在哪篇论文/演讲中提到了这一点）基于细胞。

— 弗兰克·希勒

1

我声称使用物理对象作为示例与使用非物理对象作为示例几乎没有区别。在代码中，它们都具有完全相同的部分。如果我们使用图形示例，并用球体，立方体，圆柱体进行授课，则其与使用球，盒，杆等几乎相同。

因此，要在不使用物理示例的情况下进行授课，我建议根本不使用任何示例，但是我不明白为什么您不希望使用物理示例，因此我在该主题上的立场是

不，没有物理现实世界的物体，您不应该教它

— 提姆
source

1

我看不出如何避免从现实世界的隐喻开始，但是您不想呆在那里。如果您正确地进行OOP，它很快就会变得抽象，但是在下一个理解水平上，学习者应该将对象理解为对象。

— 1936年
source

1

有趣的是，我最喜欢的一些例子不是物理对象。以银行帐户为例。每个人都“明白”为什么deposit（）和withdraw（）应该收取服务费，而不是依靠调用代码来更改余额的值并记住要收取服务费。屏幕上的形状是双重无形的，Stroustrup告诉我，经典的“ Shapes”示例是他所知道的两个最古老的OO示例之一，距今已有40年了（另一个是车辆，现已有44年的历史了。）

重要的是人们立即理解您的示例。电梯仅对熟悉电梯的人有很好的榜样。等等。

— 凯特·格里高利
source

1

如果您在编程小组中，请几个人聚在一起，然后开始讨论如何告诉彼此做您需要系统做的事情。从字面上看，您可以在系统中扮演角色（您可以通过扮演每个角色来自己完成任务，但是对于一群人来说更容易。如果您是一个人，则玩具会有所帮助）。关注每个人在做什么/将要做什么，而不是关注他们拥有的数据。与人一起做有助于将重点放在消息和角色上，因为人们倾向于记住自己在做什么，而不是记住自己拥有的数据。

注意彼此必须做的事情，以及需要做些什么信息。要保护自己的数据，如果另一个程序员索要您的数据时说不，并问他为什么需要它（有助于数据封装）。

— 科马克·穆哈尔（Cormac Mulhall）
source

还要补充一点，这是一种很好的方法，可以确定您是否有仅是数据收集的对象，因为最终您将得到一个几乎无所事事的人。然后想想对象数据在哪里使用，将这些数据简单地包含在那些对象中是否有意义？

— Cormac Mulhall

0

我认为自下而上/金属方法可能会有用。首先说明C风格的结构和指针，以说明如何构造数据，而不仅仅是直接使用基元。然后解释后期绑定和函数指针。然后说明您可以使用它们来构建对象，这些对象基本上是封装良好的数据堆，并指向操作所述数据所需的函数的指针。

这种解释与独立于实现的传统数学/ comp sic教学方法相矛盾，但这是使我（公认的具有工程学背景，而不是comp sci背景的人）最终获得面向对象的观点。

— dsimcha
source