OOP 中的抽象：多个但相当不同的上下文？ [关闭]答案

【问题标题】：Abstraction in OOP: multiple, yet rather distinct, contexts? [closed]OOP 中的抽象：多个但相当不同的上下文？ [关闭]
【发布时间】：2017-12-31 06:49:49
【问题描述】：

我一直在对 OOP 概念进行一些研究，但在尝试理解抽象到底是什么时遇到了一些问题。我浏览了很多关于该主题的 Stack Overflow 帖子，但还没有真正找到令人满意的答案。

我看到很多关于抽象和封装之间区别的讨论，自然而然地开始从以下方面思考抽象隐藏特定类的工作方式并通过类 API 提供抽象。以下是一些引导我朝这个方向发展的帖子：

但是，当我阅读更多帖子时，我注意到在继承上下文中描述抽象的答案，特别是使用接口和抽象类来提供某个实体的抽象（班级）。我假设以这种方式给出的 Abstraction 将允许开发人员根据此 Abstraction 概述的“准则”适当地扩展新对象。以下是一些将我引向这个方向的帖子：

我不确定我是否完全错过了这里的重点，但它变得非常令人困惑，因为每个答案似乎都在混合中添加了轻微的变化。我绝对明白为什么这两种上下文在面向对象编程中都很重要，但我真的想要一个明确的抽象定义。

这让我明白了：抽象在多种情况下是否有效？抽象是否同时描述了这两个概念？

隐藏“不必要的细节”，就像通过接口和抽象类
- 为要通过接口和抽象类创建的类提供抽象。我们可以提供一个IPet 的接口，它可以作为Dog 类的抽象。此外，我们可以提供一个Animal 基类作为抽象类来提供更高级别的抽象。这可以让我们使用多态性并允许属于我们Animal 抽象的不同类相互交互。
通过类 API 公开类的实现来抽象类的实现
- 给定一个Dog 类，我们只需要知道它有一个feed() 函数作为其API 的一部分，并调用该函数来馈送它，而无需知道馈送实际上是如何完成的。这提供了Dog 类的抽象，让我们可以轻松地与该类进行交互

我上面包含的一个链接包含 Matthew Watson 的以下引用：

“问题是这些概念没有精确的定义，即使在面向对象的上下文中，这些词本身也有多重含义。”

难道只是抽象这么抽象，连定义都是抽象的:P？感谢您提前提供任何指导！

编辑：我对 SO 比较陌生，并不真正了解“主要基于意见”标志的含义。我看不出这个问题比关于 SO 上的抽象的一系列问题更有效。我认为它会被认为不那么基于意见，因为我实际上是在指出我认为抽象在其中有意义的两种不同背景。我看到很多问题只是问抽象是什么，我认为这是一个更广泛的问题问题比我在这里。

【问题讨论】：

我完全同意马修·沃森的观点。我认为每个人对抽象的定义都略有不同。但我想每个人都会同意第 1 点和第 2 点都可以被视为抽象的一个例子。

标签： oop inheritance design-patterns abstraction

【解决方案1】：

对我来说，抽象是 oo 最美丽的概念之一，这实际上是使程序语言非常接近人类思维的原因：我们人类总是想要分类。想想一辆车：你的车。让我们在银行家在贷款的情况下询问你的资产的情况下接近那辆车：你会说你有资产（最高抽象级别）：一辆昂贵的汽车、一辆家用汽车、一栋房子、一艘船等. 它们都有特定的价值。然后假设对话的上下文切换到对那辆车有个人兴趣的银行家，因为他自己就是一个汽车狂。现在将更详细地描述汽车，您可以看到定义的不同抽象级别：具有品牌名称的跑车，以及更多特征。

在设计期间，您的兴趣在于抽象级别：您想用它做什么，即它的上下文。因此，我们将具有抽象级别：资产、汽车（以及船和房屋）、SportCar、FamilyCar。等等。上下文不应该有比它需要的更多的细节，这是你在设计阶段所关心的。

在实现阶段，您将通过封装属于这些级别的属性来实现这些抽象级别。例如。资产具有价值，其中 Car 具有颜色，而 SportCar 可能具有 FamilyCar 所没有的某些特定特征。

因此，关键区别在于：设计时间与实施时间。

这篇博文详细描述了不同之处： http://javarevisited.blogspot.be/2017/04/difference-between-abstraction-and-encapsulation-in-java-oop.html

这是另一个在 stackoverflow 上的帖子：What's the difference between abstraction and encapsulation?

希望这会有所帮助。

【讨论】：

我真的很喜欢您的示例（设计阶段和实施阶段的抽象）如何将我指出的两个案例联系在一起。我认为将一个面向设计，另一个面向实现是有意义的。至于您列出的第二个链接，那是我浏览的众多帖子之一。我认为这篇文章很好地解释了抽象如何在继承关系中工作，但未能将它与您所拥有的实际实现部分联系在一起。如果我在不久的将来没有收到更令人信服的答案，我会接受这个答案。
我期待：一个更有说服力的答案或接受。谢谢
我认为混淆的主要来源是大多数解释说抽象是在设计级别，而封装是在实现级别（在您链接的博客文章中也提到过）。这至少让我认为通过类 API 公开一个类将被视为封装而不是抽象。但我仍然认为允许其他对象和开发人员通过一组精心设计的 API 访问一个类（一个复杂的）对象的概念是“抽象”正在处理的类。
我认为这是一个很好的观点。我感觉到设计和实现之间的那个时刻，这个阶段并不总是完全清楚。事实上，我喜欢这样的想法，即设计无论如何都是一个连续的过程。所以设计和实现之间的区别是模糊的，因此我也认为抽象和封装之间的区别是模糊的。
我觉得这次对话会演变为辩论设计和实施发生的地点和时间......这让我想到了 Martin Fowler 的这篇精彩帖子：martinfowler.com/articles/designDead.html

【解决方案2】：

对我来说，抽象是指你完全不深入细节地解决问题。如果您需要输出汽车列表，那么我不认为“获取汽车列表，遍历它们，获取数据，打印它们”，而是认为“我需要一组对象，最好是汽车，可以显示以我需要的格式提供关于他们自己的数据。”。更多的是关于思维方式。

【讨论】：