OOP 中的抽象：多个但相当不同的上下文？
Abstraction in OOP: multiple, yet rather distinct, contexts?
我一直在研究 OOP 概念，但在尝试理解 Abstraction 究竟是什么方面遇到了一些问题。我浏览了很多关于该主题的 Stack Overflow 帖子，但未能真正找到令人满意的答案。
看到很多关于Abstraction和Encapsulation的区别的讨论，很自然地开始思考[=42] =]抽象 隐藏特定 class 的工作方式并通过 class API 提供抽象。以下是一些引导我朝这个方向发展的帖子：
- Best voted answer refers to functions being Abstract. The very next answer starts talking about abstract classes...
- Best voted answer seems to refer to exposing through the class API while the next two goes off in an Inheritance setting. Third answer even suggests Composition and Aggregation is considered an Abstraction
然而，当我阅读更多帖子时，我注意到在继承上下文中描述 抽象 的答案，特别是使用接口和抽象 classes 来提供 抽象 某个实体 (class)。我假设以这种方式给出的 Abstraction 将允许开发人员根据此 Abstraction 概述的 "guidelines" 适当地扩展新对象。以下是一些引导我朝这个方向发展的帖子：
- First couple of answers talk about Abstraction in an abstract class/interface setting, while some down the line start talking about exposing classes through APIs
- Top two voted answers refer to abstract classes/interfaces
我不确定我是否完全忽略了这里的要点，但它变得非常混乱，因为每个答案似乎都对组合添加了细微的变化。我很清楚为什么这两种上下文在面向对象编程中都很重要，但我真的想要一个明确的抽象定义。
这让我想到了我的观点：抽象 是否适用于多种环境？ 抽象是否描述了这两个概念？
隐藏起来 "unnecessary details" 通过界面和
摘要 classes
- 提供对要通过接口和抽象 classes 创建的 class 的抽象。我们可以提供一个
IPet 的接口，它可以作为 Dog class 的抽象。此外，我们可以提供一个 Animal 基础 class 作为抽象 class 以提供更高级别的抽象。这可以让我们使用多态性并允许属于我们 Animal 抽象的不同 classes 相互交互。
通过 class API
公开它来抽象 class 的实现
- 给定一个
Dog class，我们只需要知道它有一个 feed() 函数作为其 API 的一部分，并调用该函数来喂养它不知道喂食实际上是如何进行的。这提供了对 Dog class 的抽象，让我们可以轻松地与 class 进行交互
我在上面包含的其中一个链接包含 Matthew Watson 的以下引述：
"The problem is that there are no precise definitions for these concepts, and the words themselves have multiple meanings even within the context of object orientation."
难道只是Abstraction太抽象了，连定义都抽象了:P？感谢您提前指导！
编辑：我对 SO 比较陌生，并不太了解 "primarily opinion based" 标志的含义。我看不出这个问题比关于 SO 抽象的一系列问题更有效。我认为它会被认为不那么基于意见，因为我实际上是在指出两个不同的上下文，我认为抽象在其中是有意义的。我看到很多问题只是问什么是抽象，我认为这是一个更广泛的问题问题比我这里有什么。
对我来说，抽象是 oo 最美丽的概念之一，这实际上是使程序语言非常接近人类思维的原因：我们人类总是想要分类。想想一辆车：你的车。让我们在银行家询问您在贷款的情况下的资产的情况下接近那辆车：您会说您有资产（最高抽象级别）：一辆昂贵的汽车、一辆家用汽车、一所房子、一艘船等. 他们都有特定的价值。然后假设谈话的上下文切换到对那辆车有个人兴趣的银行家，因为他自己就是一个汽车狂。现在将对汽车进行更详细的描述，您可以看到定义了不同的抽象级别：带有品牌名称的跑车，以及更多特性。
在设计期间，您感兴趣的是抽象级别：您想用它做什么，即它的上下文。因此，我们将具有抽象级别：资产、汽车（以及船和房屋）、运动车、家庭车。等等。上下文永远不应包含比其需要更多的细节，这就是您在设计阶段所关心的。
在实现阶段，您将通过封装属于这些级别的属性来实现这些抽象级别。例如。资产有一个值，其中 Car 有颜色，而 SportCar 可能有一些 FamilyCar 没有的特定特征。
因此，关键区别在于：设计时间与实施时间。
这篇博客 post 非常详细地描述了差异：
http://javarevisited.blogspot.be/2017/04/difference-between-abstraction-and-encapsulation-in-java-oop.html
这是 Whosebug 上的另一个 post：What's the difference between abstraction and encapsulation?
希望对您有所帮助。
对我来说，抽象就是当你解决问题时根本不深入细节。如果你需要输出汽车列表，那么我不认为 "take a list of cars, walk through them, get their data, print them"，我认为 "I need a set of objects, preferably cars, that can display data about themselves in the format that I need."。更多的是思维方式。
我一直在研究 OOP 概念，但在尝试理解 Abstraction 究竟是什么方面遇到了一些问题。我浏览了很多关于该主题的 Stack Overflow 帖子，但未能真正找到令人满意的答案。
看到很多关于Abstraction和Encapsulation的区别的讨论，很自然地开始思考[=42] =]抽象 隐藏特定 class 的工作方式并通过 class API 提供抽象。以下是一些引导我朝这个方向发展的帖子：
- Best voted answer refers to functions being Abstract. The very next answer starts talking about abstract classes...
- Best voted answer seems to refer to exposing through the class API while the next two goes off in an Inheritance setting. Third answer even suggests Composition and Aggregation is considered an Abstraction
然而，当我阅读更多帖子时，我注意到在继承上下文中描述 抽象 的答案，特别是使用接口和抽象 classes 来提供 抽象 某个实体 (class)。我假设以这种方式给出的 Abstraction 将允许开发人员根据此 Abstraction 概述的 "guidelines" 适当地扩展新对象。以下是一些引导我朝这个方向发展的帖子：
- First couple of answers talk about Abstraction in an abstract class/interface setting, while some down the line start talking about exposing classes through APIs
- Top two voted answers refer to abstract classes/interfaces
我不确定我是否完全忽略了这里的要点，但它变得非常混乱，因为每个答案似乎都对组合添加了细微的变化。我很清楚为什么这两种上下文在面向对象编程中都很重要，但我真的想要一个明确的抽象定义。
这让我想到了我的观点：抽象 是否适用于多种环境？ 抽象是否描述了这两个概念？
隐藏起来 "unnecessary details" 通过界面和 摘要 classes
- 提供对要通过接口和抽象 classes 创建的 class 的抽象。我们可以提供一个
IPet的接口，它可以作为Dogclass 的抽象。此外，我们可以提供一个Animal基础 class 作为抽象 class 以提供更高级别的抽象。这可以让我们使用多态性并允许属于我们Animal抽象的不同 classes 相互交互。
- 提供对要通过接口和抽象 classes 创建的 class 的抽象。我们可以提供一个
通过 class API
公开它来抽象 class 的实现- 给定一个
Dogclass，我们只需要知道它有一个feed()函数作为其 API 的一部分，并调用该函数来喂养它不知道喂食实际上是如何进行的。这提供了对Dogclass 的抽象，让我们可以轻松地与 class 进行交互
- 给定一个
我在上面包含的其中一个链接包含 Matthew Watson 的以下引述：
"The problem is that there are no precise definitions for these concepts, and the words themselves have multiple meanings even within the context of object orientation."
难道只是Abstraction太抽象了，连定义都抽象了:P？感谢您提前指导！
编辑：我对 SO 比较陌生，并不太了解 "primarily opinion based" 标志的含义。我看不出这个问题比关于 SO 抽象的一系列问题更有效。我认为它会被认为不那么基于意见，因为我实际上是在指出两个不同的上下文，我认为抽象在其中是有意义的。我看到很多问题只是问什么是抽象，我认为这是一个更广泛的问题问题比我这里有什么。
对我来说，抽象是 oo 最美丽的概念之一，这实际上是使程序语言非常接近人类思维的原因：我们人类总是想要分类。想想一辆车：你的车。让我们在银行家询问您在贷款的情况下的资产的情况下接近那辆车：您会说您有资产（最高抽象级别）：一辆昂贵的汽车、一辆家用汽车、一所房子、一艘船等. 他们都有特定的价值。然后假设谈话的上下文切换到对那辆车有个人兴趣的银行家，因为他自己就是一个汽车狂。现在将对汽车进行更详细的描述，您可以看到定义了不同的抽象级别：带有品牌名称的跑车，以及更多特性。
在设计期间，您感兴趣的是抽象级别：您想用它做什么，即它的上下文。因此，我们将具有抽象级别：资产、汽车（以及船和房屋）、运动车、家庭车。等等。上下文永远不应包含比其需要更多的细节，这就是您在设计阶段所关心的。
在实现阶段，您将通过封装属于这些级别的属性来实现这些抽象级别。例如。资产有一个值，其中 Car 有颜色，而 SportCar 可能有一些 FamilyCar 没有的特定特征。
因此，关键区别在于：设计时间与实施时间。
这篇博客 post 非常详细地描述了差异： http://javarevisited.blogspot.be/2017/04/difference-between-abstraction-and-encapsulation-in-java-oop.html
这是 Whosebug 上的另一个 post：What's the difference between abstraction and encapsulation?
希望对您有所帮助。
对我来说，抽象就是当你解决问题时根本不深入细节。如果你需要输出汽车列表，那么我不认为 "take a list of cars, walk through them, get their data, print them"，我认为 "I need a set of objects, preferably cars, that can display data about themselves in the format that I need."。更多的是思维方式。