泄漏抽象律例外

我和一位友善的编码员发生了争执，他被乔尔的Law of Leaky Abstractions轻度损坏。要说服他使用任何新的框架/工具箱是非常困难的。我试图提出一个观点，“只要抽象层次允许低层访问，抽象就没有问题”。泄漏抽象律例外

例子：

GWT - 谷歌的精湛Java到JavaScript编译器，具有JSNI - 笔头 “原生” 的JavaScript，如果你真的想。
Hibernate - AFAIK拥有SQLQuery - 编写原生SQL的方式。
爪哇 - JNI - 如果你错过C.

是它的声音？我错过了什么吗？

感谢

来源

2009-01-26 Yoni Roit

那么，你的问题到底是什么？如果这个人不会使用任何框架或工具箱，因为没有完美的摘要，那么这个人的思想就有一些基本的问题。 – BobbyShaftoe 2009-01-26 11:48:18

我试图验证我的论点，而不仅仅依赖于我自己的观点。 – 2009-01-26 11:53:20

这很奇怪。我记得几年前阅读过这篇文章，我从来没有想过Joel在谴责抽象，他只是说他们并不总是像“优雅”的程序员认为的那样整洁。在设计抽象时，重要的是要考虑实现可能如何泄露;但抽象仍然是必不可少的......编写一个不重要的应用程序是一项如此庞大的任务，除非您可以使用抽象来“掩盖”其他部分，而只关注一个部分，否则无法理解一个庞大的系统。 – 2011-06-23 02:09:21

我从阅读漏抽象的文章了什么没有那么抽象是坏的，但是，你应该让一个角度来理解引擎盖下发生的事情，这样就可以解释“意外“行为，并避免它们。

你的朋友在什么程序？机器语言？ :)

来源

2009-01-26 11:45:56

虽然我认为每个抽象都是有漏洞的，但这并不一定是坏事。例如，在传统的普通C（C＃，Java，无论）代码中，你通常使用循环，ifs等从数组中检索数据。但是这样你就可以对问题进行过度指定。

SQL，Linq方式同样的问题的方法更聪明：你只是说你想要什么，机器会计算出如何去做。这样它就没有任何特定的传统命令顺序，可以将工作分解为不同的cpus，或者重新排序，以便更好地使用缓存等。

所以是的，你对机器给予了一些控制，但是这台机器比你有一个巨大的优势：它在用户/客户的地方，并且这种方式可以做出按需决定（如使用多核，使用MMX的优势，无论如何）。

来源

2009-01-26 11:52:42 Lemmy

乔尔的观点（据我所知）是通过将复杂性抽象出来，你牺牲了对底层复杂性的更好控制。除了微不足道的情况之外，您最终需要访问更精细的控制粒度，在此时抽象会被破坏。

因此，所有的抽象是漏水的（几乎）定义：

如果有复杂的系统，它一定是有原因的（或你应该找到一种方法来删除它），因此将偶尔有用/至关重要。
通过抽象你正在限制你对底层复杂性的控制。
当这些'偶尔会出现，你将不得不打破抽象。

来源

2009-01-26 11:53:35

在某种程度上他有一个观点。传统的c/unix开发工作到一个足够简单的平台，能够全面或多或少地理解。现代平台的数量级要复杂得多，并且了解所有层的相互作用如何更难，往往不可行。

泄漏抽象的定律主要适用于框架在管理底层复杂性方面做得不好的情况。框架可以被判断的一些方式是它的透明度（易于理解幕后发生的事情）以及它能够摒弃自定义的解决方法来限制其功能。

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

当一个框架阻碍你解决它的限制时，它就成为开发的一个障碍。当这种情况经常发生时，代码库就会被封入或者被越来越多的混乱的黑客所污染，以解决这些问题。这也会导致稳定性和调试问题，例如存在这些缺陷的框架比比皆是。 MFC由于未能隐藏Win32的底层复杂性而相当出名。它还广泛使用了向导，这些向导生成的杂乱代码需要经过手动修改，这首先破坏了代码生成器的功能。早期的Java GUI工具包（AWT和Swing的早期版本）在桌面应用程序中很少被采用，因为它们阻碍了开发人员为应用程序实现本机外观。由于Swing的这些限制，SWT的构建不在少数。然而，现在Java已经成熟了一点，可以说它的大多数早期罪已经在现代框架中得到修复。 J2EE仍然是一个庞大而复杂的系统，在浏览器中开发一个非平凡的用户界面也是相当重要的任务。精通这个平台是相当多的工作。然而，这并不能超越人的智慧。

来源

2009-01-26 12:05:57 ConcernedOfTunbridgeWells

泄漏抽象律例外

回答

相关问题