Question

当您需要为人员（例如请求构建器）创建多个嵌套的构建器时，如何处理API客户端的抽象。

我需要在业务逻辑中使用外部支付服务来存储用户的内部帐户。通常，我需要发送如下所示的JSON：

{
  "amount": {
    "value": "200.50",
    "currency": "RUB"
  },
  "description": "Some text",
  "confirmation": {
    "type": "redirect",
    "return_url": "https://site.ru"
  },
  "payment_method": "bankcard"
}

我做了很多合同（接口），可以做到这一点：

$request = $gateway->createPayment()
    ->setAmount('200.50', 'RUB')
    ->setDescription('some text')
    ->confirmation()
        ->redirect()->setReturnUrl('https://site.ru')

$request->paymentMethod()->bankcard();

return $request;

confirmation()和paymentMethod()是问题。这些是单独的接口，但是它们内部包含诸如redirect()之类的方法，这些方法会返回另一个接口。

还有另一个请求选项，可以包含更大的嵌套深度。对于每个嵌套级别，我都应该创建一个接口。

如果我使用类似$payment->setConfirmation(new Redirect('https://site.ru'))的东西（其中Redirect是ConfirmationInterface的实现，那会更舒服，但是我不能这样做，因为Redirect是一个{具体的实现，但是我想使我的业务逻辑服务与实现完全脱钩，所以我不能创建任何不依赖于业务服务层的实例。

那么也许您知道另一种方法来使其更坚固美观？

API客户端的抽象

0 个答案: