泄漏抽象的含义？

Question

“泄漏抽象”一词是什么意思？ （请举例说明。我经常很难理解纯粹的理论。）

Answer 1

这是一个 meatspace 示例：

汽车对驾驶员有抽象。最纯粹的形式是有方向盘、加速器和制动器。这种抽象隐藏了很多关于引擎盖下的细节：发动机、凸轮、正时皮带、火花塞、散热器等。

这种抽象的巧妙之处在于，我们可以用改进的部件替换部分实现，而无需重新培训用户。假设我们用电子点火装置替换分电器盖，并用可变凸轮替换固定凸轮。这些变化提高了性能，但用户仍然用方向盘转向并使用踏板启动和停止。

这实际上是相当了不起的……一个 16 岁或一个 80 岁的人可以操作这台复杂的机器，而无需真正了解它的内部工作原理！

但也有泄漏的情况。传动装置有小泄漏。在自动变速箱中，您可以感觉到汽车在换档时暂时失去动力，而在 CVT 变速箱中，您会感觉到扭矩一直平稳上升。

还有更大的泄漏。如果发动机转速太快，可能会对其造成损坏。如果发动机缸体过冷，汽车可能无法启动或性能不佳。如果你同时打开收音机、车头灯和空调，你会发现你的油耗会下降。

Answer 2

它只是意味着你的抽象公开了一些实现细节，或者说你在使用抽象时需要了解实现细节。该术语源自 Joel Spolsky，约 2002 年。请参阅维基百科 文章 了解更多信息。

一个典型的例子是网络库，它允许您将远程文件视为本地文件。使用此抽象的开发人员必须意识到网络问题可能会导致其失败，而本地文件则不会。然后，您需要开发代码来处理网络库提供的抽象之外的特定错误。

Answer 3

维基百科对此有一个相当好的定义

泄漏抽象是指任何实现的抽象，旨在降低（或隐藏）复杂性，其中底层细节并未完全隐藏

或者换句话说，对于软件来说，当您可以通过程序中的限制或副作用观察功能的实现细节时。

一个简单的例子是 C# / VB.Net 闭包及其无法捕获 ref / out 参数。无法捕获它们的原因是提升过程如何发生的实现细节。但这并不是说有更好的方法可以做到这一点。

Answer 4

下面是 .NET 开发人员熟悉的一个示例：ASP.NET 的 Page 类尝试隐藏 HTTP 操作的细节，特别是表单数据的管理，以便开发人员不必处理发布的值（因为它会自动将表单值映射到服务器控件）。

但是，如果您超出了最基本的使用场景，Page 抽象就会开始泄漏，并且除非您了解类的实现细节，否则很难使用页面。

一个常见的示例是向页面动态添加控件 - 动态添加的控件的值不会为您映射，除非您在恰好的时间添加它们：在底层引擎映射传入表单之前值到适当的控制。当您必须了解这一点时，抽象就已经泄露了。

Answer 5

嗯，在某种程度上，这纯粹是理论上的事情，尽管并非不重要。

我们使用抽象来使事情更容易理解。我可能会对某种语言的字符串类进行操作，以隐藏我正在处理作为单独项目的有序字符集的事实。我处理一组有序的字符，以隐藏我正在处理数字的事实。我处理数字是为了隐藏我正在处理 1 和 0 的事实。

泄漏抽象是指没有隐藏其本应隐藏的细节的抽象。如果在 Java 或 .NET 中调用 string.Length 5 个字符的字符串，我可以获得 5 到 10 之间的任何答案，因为实现细节中这些语言调用的字符实际上是 UTF-16 数据点，可以表示 1 或.5 个字符。抽象已经泄露。不过，不泄漏意味着查找长度要么需要更多的存储空间（用于存储实际长度），要么从 O(1) 变为 O(n)（以计算出实际长度）。如果我关心真正的答案（通常你并不关心），你需要努力了解到底发生了什么。

更多有争议的情况发生在诸如方法或属性允许您了解内部工作原理的情况下，无论它们是抽象泄漏，还是转移到较低抽象级别的明确定义的方法，有时可能是人们不同意的问题。

Answer 6

我将继续使用 RPC 来举例。

在 RPC 的理想世界中，远程过程调用应该看起来像本地过程调用（或者故事是这样的）。它对程序员来说应该是完全透明的，这样当他们调用 SomeObject.someFunction() 时，他们不知道 SomeObject （或者只是 someFunction）那个问题）是本地存储和执行或远程存储和执行。从理论上讲，这使得编程变得更简单。

现实情况有所不同，因为进行本地函数调用（即使您使用的是世界上最慢的解释语言）和：

• 通过代理对象
• 调用 序列化参数
• 建立网络连接（如果尚未建立）
• 传输 将数据传输到远程代理
• 让远程代理恢复数据并代表您调用远程函数
• 序列化返回值
• 将返回值传输到本地代理
• 重新组装序列化数据
• 从远程函数返回响应

仅在时间内大约三个数量级（或更多！）的差异。这三个以上的数量级将在性能上产生巨大的差异，当您第一次错误地将 RPC 视为真正的函数调用时，这将使过程调用的抽象泄漏变得相当明显。此外，除非代码中存在严重问题，否则真正的函数调用除了实现错误之外几乎不会有任何故障点。 RPC 调用具有以下所有可能的问题，这些问题将作为失败案例而出现，超出了您对常规本地调用的预期：

• 您可能无法实例化您的本地代理
• 您可能无法实例化您的 本地代理远程代理
• 代理可能无法连接
• 您发送的参数可能无法使其完整或根本无法使其完整
• 远程发送的返回值可能无法使其完整或根本

因此现在您的 RPC 调用“就像本地函数调用一样” “在执行本地函数调用时，您不必应对大量额外的故障情况。抽象概念再次泄露，而且更加严重。

最后，RPC 是一个糟糕的抽象，因为它在每个级别都像筛子一样泄漏——无论成功还是失败。

Answer 7

什么是抽象？

• 抽象是简化世界的一种方式。
• 这意味着您不必担心幕后实际发生的情况。

示例：驾驶 737/747 是“抽象”的 飞机

• 是复杂的系统：它涉及：喷气发动机、氧气系统、电气系统、起落架系统等
• ......但飞行员不必担心。所有这些都被“抽象化”了。飞行员唯一需要关注的是操纵杆（即飞机的方向盘）。
• 他将轭向左推向左，向右推向右，等等

……这是在一个理想的世界中。事实上，驾驶飞机要复杂得多。因为许多细节并没有被“抽象掉”。

737 示例中的抽象漏洞

现实中，飞行员必须担心很多事情：风速、推力、迎角、燃料、高度、天气问题、下降角。计算机可以帮助飞行员完成这些任务，但并不是所有事情都是自动化/简化的……并不是所有事情都是“抽象出来的”。

例如，如果飞行员在立柱上拉得太用力 - 飞机会服从，但随后飞机可能会失速，这真的很糟糕。

换句话说，飞行员在不了解其他任何事情的情况下仅仅控制方向盘是不够的......不......飞行员必须了解潜在的风险和局限性在飞行员驾驶飞机之前……飞行员必须知道飞机是如何工作的，以及飞机是如何飞行的；飞行员必须知道实施细节......拉得太用力会导致失速，或者着陆太陡会毁坏飞机等等。

这些事情是没有被抽象掉。很多东西都是抽象的，但不是一切。抽象是“泄漏的”。

代码中的抽象泄漏

......这与您的代码中的情况相同。如果你不知道底层的实现细节，那么你就会遇到问题。

ORM 抽象了处理数据库查询时的很多麻烦，但如果您曾经做过类似的事情：

User.all.each do |user|
   puts user.name # let's print each user's name
end

那么您会意识到这是杀死您的应用程序的好方法。您需要知道，对 2500 万用户调用 User.all 会增加您的内存使用量，并会导致问题。您需要了解一些基本细节。抽象是有漏洞的。

参考文献：

• https://www.joelonsoftware.com /2002/11/11/抽象泄漏定律/

Answer 8

django ORM 多对多示例中的示例：

示例 API 中的通知在将 Publication 对象添加到多对多属性之前，您需要 .save() 基本 Article 对象 a1 的用法。请注意，更新多对多属性会立即保存到底层数据库，而更新单个属性直到调用 .save() 才会反映在数据库中。

抽象是我们正在使用对象图，其中单值属性和多值属性只是属性。但是，作为关系数据库支持的数据存储的实现存在泄漏……因为 RDBS 的完整性系统是通过对象接口的薄薄的外表出现的。

Answer 9

事实上，在某个时候，根据您的规模和执行情况，您将需要熟悉抽象框架的实现细节，以便理解它为什么会这样做。

例如，考虑这个 SQL 查询：

SELECT id, first_name, last_name, age, subject FROM student_details;

及其替代方案：

SELECT * FROM student_details;

现在，它们看起来确实是逻辑上等效的解决方案，但由于各个列名称规范，第一个解决方案的性能更好。

这是一个微不足道的例子，但最终还是回到了 Joel Spolsky 的名言：

所有重要的抽象在某种程度上都是有漏洞的。

在某些时候，当您的运营达到一定规模时，您将希望优化数据库 (SQL) 的工作方式。为此，您需要了解关系数据库的工作方式。它一开始就被抽象给你了，但它是有漏洞的。你需要在某个时候学习它。

Answer 10

假设我们在库中有以下代码：

Object[] fetchDeviceColorAndModel(String serialNumberOfDevice)
{
    //fetch Device Color and Device Model from DB.
    //create new Object[] and set 0th field with color and 1st field with model value. 
}

当消费者调用 API 时，他们会得到一个 Object[]。消费者必须了解对象数组的第一个字段具有颜色值，第二个字段是模型值。这里，抽象已从库泄漏到消费者代码。

解决方案之一是返回一个封装了设备型号和颜色的对象。消费者可以调用该对象来获取模型和颜色值。

DeviceColorAndModel fetchDeviceColorAndModel(String serialNumberOfTheDevice)
{
    //fetch Device Color and Device Model from DB.
    return new DeviceColorAndModel(color, model);
}

Answer 11

泄漏抽象都是关于封装状态的。泄漏抽象的非常简单的示例：

$currentTime = new DateTime();

$bankAccount1->setLastRefresh($currentTime);
$bankAccount2->setLastRefresh($currentTime);
$currentTime->setTimestamp($aTimestamp);

class BankAccount {
    // ...

    public function setLastRefresh(DateTimeImmutable $lastRefresh)
    {
        $this->lastRefresh = $lastRefresh;
    } }

以及正确的方法（不是泄漏抽象）：

class BankAccount
{
    // ...

    public function setLastRefresh(DateTime $lastRefresh)
    {
        $this->lastRefresh = clone $lastRefresh;
    }
}

更多描述 这里。