Question

不确定标题是否足够有用，我想知道在创建面向对象的库时最佳实践和最佳设计模式是什么-“客户端”应负责清理发送给“黑色”的数据框”库还是该库应提供防止恶意内容的工具集。

我将举一个例子：假设我们正在构建一个开放源代码库，该库提供与虚拟服务fooCompany的集成，该服务提供REST API。现在，我们的库需要向这些API发出请求并为其提供一些数据，在我们的示例中，我们以身份验证令牌为例。

最简单的代码可能看起来像这样：

class fooCompany {
  private $apiToken;

  public function __construct($apiToken) {
    $this->apiToken = $apiToken;
  }

  public function send() {
    $ch = curl_init('https://fooCompany.xx/api/send');
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        'Content-Type: application/json',
        'Authorization: Bearer ' . $this->apiToken
    ));

    $data = curl_exec($ch);
    curl_close($ch);
  }
}

我们可以看到，如果使用我们库的客户端应用程序无法很好地保护apiToken，则其应用程序现在将容易受到标头注入攻击。

谢谢。

Answer 1

我想，对于这种问题，没有简单的解决方案。基本上，您所描述的是可以（或不能）添加到“产品”中的功能。据我了解，这根本与oop无关。这是您必须做出的战略决策。而且-当然-依赖：

作为图书馆作者，您应该始终问自己，您的lib将在何处，何时，为什么以及由谁使用。

总的来说，人们在考虑图书馆时会抱有一定的期望，并且肯定会变得懒惰。

与基础核心的整洁，可靠，已记录的错误预防接口将始终受到高度赞赏。客户代码将自动获得质量，并且更易于维护。每个人都喜欢。与图书馆的大多数用户相比，作为图书馆作者的您将始终对“称为fooCompany的虚拟服务”有更好的了解。您可以在几分钟内解决问题。其他人可能需要几天的时间。

显然，这需要您做很多工作...

（当然），与安全相关的事务显然也很容易：如果您已经预料到会发生某些事情，那么您当然应该在这里付出一些努力。

健壮性原则说：对自己的工作要保守，对别人的期望要宽松。

您询问了设计模式：清楚地标识您的lib库中应明确使用/调用的客户端代码部分。那就是公共api 。其他所有内容都被视为内部或核心。理想情况下，内部内容完全不应该向客户公开（如果可能）。

通过分解，您可以专注于不同的目标。内部零件技术含量高，预计会经常更改。如果愿意的话，它会做得很重。公共api还有其他优先级。它应该方便，易于理解并且要考虑（向后）兼容性。这样，您就可以进行某些更改，而这些更改根本不需要触摸客户端代码。

此外，如果您发布并维护某些内容，请遵循semantic versioning的规则。人们会喜欢的。

验证/消毒和OOP

1 个答案: