api - 抽象正在使用的 API 是一种好习惯吗?

标签 api oop abstraction

<分区>

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

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

我的问题:

  1. 这是一个有效的建议吗?
  2. 这不会增加代码的复杂性吗?
  3. 这条规则有异常(exception)吗?
  4. 这不会抵消抽象和可重用性的好处吗?
  5. 在某种程度上,拥有这一层是否有意义,超出这个范围,解决方案就会显得过度设计?

提前致谢!

最佳答案

jQuery 是一种高度可用的 API,旨在在“应用程序代码”级别非常有效地工作。它不应该需要抽象化,而且您无论如何也不会从中受益。

您可能会发现在构建一些“库组件”或基于它的少量库代码时有用——分解出重复 UI 组件和模式的应用程序级使用,特定于您的应用。

一般来说,“抽象一切”的建议听起来大多是错误的。抽象用于您将要或可能必须使其可互换的事物。不需要的抽象是误导的,没有用的,除了成本之外什么都没有。

jQuery 已经是一个抽象层,所以无论是谁告诉你这个的,都不知道他们在说什么。

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

在这种情况下,构建您自己的库代码/类通常很有用——例如阅读器、编写器、构建器和其他“面向任务”的类——以供您的应用程序代码使用应用程序级API,并驱动下库。但同样,这不是抽象。

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

  1. 数据库可移植性——使用 Hibernate,不依赖特定于数据库的生成器;和
  2. 应用服务器/操作系统的可移植性。 Java 和 servlet/JSP 两者兼备。
  3. 配置。例如,通过像 Spring 这样的框架。

关于api - 抽象正在使用的 API 是一种好习惯吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19781275/

相关文章:

javascript - 来自 GitHub 页面的 API 请求不起作用 ("mixed block")

javascript - API - 使用 GET 来添加、编辑和删除?

oop - 披萨建模

javascript - 面向对象的 Javascript : How to define an object with variable form same object

nhibernate - 如何抽象 NHibernate 以避免紧依赖和促进测试

java - 从数据库中获取值的好方法

assembly - 超越抽象的好奇心 : how is bytecode executed? 设备驱动程序如何工作?

php - REST API - 相互依赖的端点试运行流程?

oop - 如何在golang中创建一个自动调用的结构方法?

python - Rdio Desktop API 是否为轨道提供唯一 ID?