PHP OOP::构建 API 包装器类

Question

我有一个应用程序，它本质上是第 3 方 API 的包装器。该应用程序不使用数据库，仅存储一个 cookie，即 API 所需的 session ID。

API 是一个购物系统，允许用户

-登录/注册/编辑个人资料/注销

-购买商品

-捐款

-成为成员(member)

API 有大约 50 个方法需要我的应用连接。示例 API 调用有 addItemToBasket()、addDonation()、GetUserDetails() 等。

我正在尝试确定我的应用程序中应该包含哪些类。这是我目前所拥有的:

类

1) APIManager() 类包含与 3rd 方 API 中公开的方法一对一匹配的方法，并提供与远程 API 服务器建立连接的机制。所以用户将通过

登录

APIManager->loginUser($sessionKey, $uid, $pwd);

并且远程 API 会将用户设置为已登录。如果需要，我的应用程序可以通过调用 API 检查任何 session key 的登录状态:

 APIManager->isLoggedIn($sessionKey);

2) User() 类这包含处理 API 调用(例如注册或登录)之前所需的业务逻辑的方法。一个示例方法是:

function login($_POST) {
    //perform sanity checks, apply business rules etc.
    //if certain conditions are met, we may pass in a promo code, $pc

    APIManager->loginUser($sessionkey, $_POST['uid'], $_POST['pwd'], $pc);
}

我意识到我可能只是从登录页面调用 APIManager，而不是拥有一个 User 类本身，但我觉得因为在我们实际调用 API 的 loginUser() 方法之前需要运行一些业务逻辑，感觉在 User 类中处理它是正确的。我很想知道人们对此有何看法。

3) Basket() 类

篮子在第 3 方 API 中进行管理，因此我的应用程序的作用是进行适当的 API 调用以将新项目添加到篮子、删除项目、查看篮子等。我的应用程序对篮子一无所知，直到数据从 API 检索，也不能在不通过 API 的情况下对购物篮进行任何更改。同样，将此相关逻辑分组到 Basket 类中感觉很合适。前端网页可能调用如下内容:

Basket->addItem(23);

Basket 类中的这个 addItem() 方法看起来像这样:

addItem($itemID) {
   //perform checks, apply business rules e.g. if user is eligible for discount
        APIManager->addToCart($itemID, $discount);
}

其中 addToCart() 是我们调用来处理商品的第三方 API 方法。

4) Donation() 类

这允许用户进行捐赠。捐赠出现在篮子中，可以从篮子中移除。我想只向 Basket 类添加一个 addDonate() 方法，根本不用担心是否有 Donation 对象，但是......(见下文)

5) Membership() 类

...成员(member)实际上是一种捐赠! API 会将进入特定帐户的捐款视为 1 年成员(member)资格，而不是普通捐款。我们无法更改第 3 方 API 的逻辑/行为。

因此，如果我向账户“1”捐赠 50 美元，那么这只是一次正常捐赠，但如果我向账户“8”捐赠 100 美元，那么我将成为成员(member)并享受所有成员(member)福利(折扣价、无邮费等) .

这里是我不确定最佳设计方式的地方。

我是否应该创建一个 Donation 类，然后使用 Membership 扩展它，因为 Membership 需要所有 Donation 方法。但是 Membership 将需要额外的方法，例如 renew() 或 getExpiry() 等。

此外，我是否应该考虑将用户扩展为成员(member)？同样，成员拥有 User 拥有的所有核心方法，但也有其他方法，例如只有成员才能访问的 getSpecialOffers() 或 getDiscountCode()。

如能提供有关如何以最佳方式进行设计的任何指导，我们将不胜感激。

谢谢，詹姆斯

Answer 1

就个人而言，我会分 3 层构建它。

第 1 层:API 接口(interface)

该层是对远程 API 进行实际行级调用的地方。这一层是关于协议(protocol)的。这一层中不应该有任何特定于 API 的内容。一切都应该是 100% 通用的，但应该能够被中间层用来与 API 交互。请注意，该层可以来自库或其他来源(如框架)。或者你可以写自定义。这完全取决于您所在的位置和您的确切需求。

一些可能属于这里的类:

• XMLRPC_Client
• SOAP_Client
• REST_Client

第 2 层API 适配器

该层实际上将 API 信息硬编码到其中。这基本上是 Adapter Pattern .基本上这一层的工作是使用接口(interface)层将远程 API 转换为本地 API。因此，根据您的需要，您可以在 1:1 庄园中镜像远程 API，或者您可以根据您的需要稍微调整一下。但要记住的是，此类不是为您的程序提供功能。目的是将远程 API 与本地代码分离。通过换出此类，您的代码应该能够快速适应使用不同版本的远程 API，甚至可能同时使用不同的远程 API。

需要记住的重要一点是，此适配器层旨在包含 API。因此，每个单独类的范围是整个 API 实现。因此，适配器和远程 API 之间应该存在 1:1 的映射。

一些可能在这里的类:

• RemoteAPI_v1_5
• RemoteAPI2_v1

第 3 层:内部对象

该层应该是不同对象的内部表示(在您的特定情况下:用户、购物篮、购物车、捐赠、成员(member)资格等)。他们不应该直接调用 API，而是使用组合(依赖注入(inject))来变成基本上是 bridge 的东西。到 API。通过保持分离，您应该能够完全独立于内部类来改变 API(反之亦然)。

因此，您的其中一个类可能如下所示:

class User {
    protected $api;
    public function __construct(iAPIAdapter $api) {
        $this->api = $api;
    }
    public function login() {
        $this->api->loginUser($blah);
    }
}

这样一来，就没有真正需要 API 管理器 可以这么说了。只需在程序开始时创建一个新的 API 实例，并将其传递给您的其余代码即可。但它的主要好处是非常灵活，您应该能够通过简单地换出代码中的适配器层(当您实例化适配器时)来更改 API(版本或调用本身)。其他一切都应该正常工作，并且您应该完全不受代码或远程 API 更改的影响(更不用说如果以这种方式构建它应该是非常可测试的)...

那是我的 0.02 美元。这可能有点矫枉过正，但这实际上取决于您的确切需求...