智能合同接口-最佳实践

Question

创建接口的一般经验法则是什么？为什么我想要一个接口，即IAugur.sol，而不是整个Augur.sol文件？有人能说明一下界面的最佳实践和利弊吗？

Answer 1

有两个主要原因。

1. 将合同规模降到最低
2. 确保遵守

如果您制定了尽可能小的合同并使用了Augor.sol，那么您的合同将至少和Augor.sol一样大。

contract Mine {
  Augor a;
}

您已经将a定义为Augor的一个实例，这意味着所有Augor字节码都卷到了您的字节码中。它没有被评估是否有用，所以它没有被使用并不会减少你的合同的规模。

如果你说：

IAugor a;

您的合同将包括接口的代码，它应该要小得多。接口是所需的全部。这是一个黑匣子，它的内部运作与此无关。只有函数签名和预期响应。

接口对于确保和演示遵从性也很有用。例如，有人可能会说“我的合同是一个ERC20令牌”。是吗?它是否实现了所有所需的功能？

你可以说：

contract MyIncompleteToken is ERC20 {} // where ERC20 is the standard interface

它将编译，但不会部署。它不会部署，因为接口部署了一些功能，而且它们没有实现。这可以帮助捕获开发人员的监督。继承的接口是实现所有承诺的功能的承诺。对于所有的兼容性问题来说，这并不是一个问题，但它是有帮助的。

希望能帮上忙。

Answer 2

因为通常在编写与其他契约交互的合同时，这些契约的内部工作并不相关，只是外部公开的函数。通过提供一个接口，其他开发人员可以编写与您的代码完美交互的代码，而无需查看/包含您的整个代码库。