抽象使用的API是一种好习惯吗?

时间:2013-11-05 03:08:02

标签: api oop abstraction

在设计软件时,我听到很多人建议,围绕调用第三方API库构建抽象层是一种很好的做法。

所以,如果我理解正确的话,比方说我正在用jQuery构建一个web应用程序。我需要围绕jQuery构建一个抽象层,并让我的其余应用程序代码使用我的抽象API与直接调用jQuery。

我的问题:

  1. 这是一个有效的建议吗?
  2. 这会不会增加代码复杂性?
  3. 这条规则有例外吗?
  4. 这会不会取消抽象和可重用性的好处吗?
  5. 这个层在某种程度上是否有意义,解决方案似乎过度设计?
  6. 提前致谢!

2 个答案:

答案 0 :(得分:2)

jQuery是一个高度可用的API,旨在在“应用程序代码”级别上非常有效地工作。它不应该需要抽象和你不会因此而受益。

您可能会发现在构建一些“库组件”或少量库代码的基础上 - 将重复UI组件的应用程序级别使用分解为&模式,特定于您的应用。

一般来说,“抽象一切”的建议听起来大多是错误的。抽象用于您将要或可能必须互换的事物。不需要的抽象是误导的,没有用的&除此之外别无其他。

jQuery已经是一个抽象层,所以谁告诉你这个并不知道他们所谈论的第一件事。

与jQuery相比,更常见的情况是使用其他库而不是抽象,它们是在“库实现”或SPI级别设计的,低于应用程序代码运行的级别。

在这种情况下,构建自己的库代码/类(例如读者,编写器,构建器和其他“面向任务的”类)通常很有用 - 应用程序代码将使用它们与应用程序级别一起使用API,并向下驱动到库。但同样,这不是抽象。

实际使用抽象的三个最有用的地方是:

  1. 数据库可移植性 - 使用Hibernate,不依赖于特定于DB的生成器;和
  2. 应用程序服务器/操作系统可移植性。 Java和servlets / JSP为您提供了这两种功能。
  3. 配置。例如,通过像Spring这样的框架。

答案 1 :(得分:1)

如果您正在构建一个相当复杂的Web应用程序(UI,交互和数据繁重),那么jQuery本身就是一个非常好的DOM操作和AJAX库,它将无法为您提供构建客户端代码以可维护的方式。

我认为你听到人们谈论的抽象是过去几年开始出现的各种客户端框架,例如BackboneKnockoutAngular和{ {3}},其中大多数使用(或可以使用)jQuery来处理它所擅长的东西,主要是DOM操作。

这些框架中的任何一个都将为您提供以模块化和可维护的方式构建代码所需的工具,而无需重新发明轮子。如果您的Web应用程序非常复杂(或者可能随着时间的推移而变得复杂),我强烈建议您将上述其中一个作为起点。