漏洞抽象法则的例外

Question

我和一位友善的编码员发生了争执，他被乔尔的Law of Leaky Abstractions轻微损坏了。要说服他使用任何新的框架/工具箱是非常困难的。我试图提出一个观点，即“抽象是好的，只要它们允许低级访问抽象级别”。

示例：

• GWT - 谷歌精湛的Java-to-Javascript编译器，具有JSNI - 能够编写“本机”Javascript，如果你真的想要。
• Hibernate - AFAIK有SQLQuery - 编写本机SQL的方法。
• Java - JNI - 如果你错过了C.

听起来不错？ 我错过了什么吗？

由于

Answer 1

我从阅读泄漏的抽象文章中得到的并不是抽象是坏的，而是你应该明白了解幕后发生的事情，以便你可以解释“意外”的行为，并避免它们。

你朋友的节目是什么？机器语言？ ：）

Answer 2

乔尔的观点（据我理解）是，通过抽象复杂性，你正在牺牲对底层复杂性的更好控制。对于除了琐碎的案例之外的任何事情，您最终都需要访问更精细的控制粒度，此时抽象就会崩溃。

因此，根据定义，所有抽象都会泄漏（几乎）：

• 如果系统存在复杂性，它必须存在（或者您应该找到一种方法将其删除），因此偶尔会有用/至关重要。
• 通过抽象，你限制了你对底层复杂性的控制。
• 当那些'偶尔出现'时，你将不得不打破抽象。

Answer 3

在某种程度上，他有一个观点。传统的c / unix开发适用于一个足够简单的平台，可以完全理解或多或少。现代平台的数量级要复杂得多，理解所有层的相互作用要困难得多，通常是不可行的。

泄漏抽象法主要适用于框架在管理底层复杂性方面做得不好的时候。可以判断框架的一些方式是它的透明度（易于理解幕后发生的事情）以及它为了限制其功能而退出自定义解决方案的能力。

当框架在幕后完成许多复杂的魔术时，诊断和故障排除变得更加困难，通常需要在框架的底层架构中拥有不成比例的大量专业知识。这意味着从框架中获得的生产力增益将被吸收到培训和调试代码的额外工作中。它还使框架难以学习和使用，这是您的C编程朋友习惯的。

当框架阻碍您解决其局限性时，它就成了发展的障碍。当这种情况经常发生时，代码库要么装箱，要么被更大更乱的黑客污染，以解决问题。这也会导致稳定性和调试问题，

具有这些缺陷的框架示例比比皆是。 MFC因未能隐藏Win32的底层复杂性而闻名。它还广泛使用了向导，这些向导生成了需要手动修改的混乱代码，从而破坏了首先使用代码生成器的目的。早期的Java GUI工具包（AWT和早期版本的Swing）在桌面应用程序中几乎没有采用，因为它们阻碍了开发人员实现应用程序的本机外观。由于Swing的这些局限性，SWT的建立在很大程度上。

然而，现在Java已经成熟了一些，可以说它的大多数早期的罪已经在现代框架中被修复了。 J2EE仍然是一个庞大而复杂的系统，在浏览器中开发一个非平凡的用户界面也是一项非常重要的工作。精通这个平台需要做很多工作。然而，它并没有超越人类的智慧。

Answer 4

虽然我认为每个抽象都是漏洞，但这并不一定是件坏事。

例如，在传统的普通C（C＃，Java，无论如何）代码中，您通常使用循环，ifs等从数组中检索数据。但是这样您就会过度指定问题的解决方案。

SQL，Linq解决同样问题的方式更加智能：你只需说出你想要的东西，机器就会知道如何去做。这样，它就不需要传统方式的任何特定命令排序，并且可以将工作分成不同的cpu，或者重新排序以更好地利用缓存等。

所以是的，你可以对机器进行一些控制，但是机器比你有一个很大的优势：它在用户/客户的位置，这样做可以做出按需决定（比如使用多核，利用MMX，无论如何）。