我需要使用可重用/可扩展的合约（接口）来构建cordapp”>
我已决定构建一个可重复使用的Cordapp平台，该平台将在需要时以最少的更新（每个合作伙伴）满足多个合作伙伴的需求。
我计划通过为州和合同创建基类来实现这一目标，这些基类应包含每种付款工具的所有可能的共同属性，并将由其他常规州和合同进行扩展。至于流程，我可以准备好所有基本的通用流程。然后可以根据需要编写定制的流程，并且（希望如此）这只是在最前面进行的最少添加。
为了实现上述计划，我最近通过测试Cordapp对其进行了尝试。
对于国家，我观察到我可能有一个具有所有可能的通用参数的（接口）状态（对于一个特定的付款工具），然后可以由其他常规国家按计划进行扩展。
对于合同，我有些挑战。
[当接口合同IXContract被扩展（通过开放类）XContract时，我收到了事务错误“合同验证失败：必需的com.template.contracts.IXContract.Commands命令，合同：com.template.contracts.XContract” 。这似乎是由单个XState使用的合同冲突引起的。
我还修改了代码，将IXContract作为开放类，将XContract作为抽象类。这返回了成功的事务，但是未捕获IXContract中的无效规则，这不是项目的预期行为。
为了避免合同冲突，我尝试了简单类的通常编程风格。对于基类IXContract，这次不扩展Contract接口（这使其不是合同类），而是包含具有合同规则的BaseContract方法。然后，我将该类自动连接到常规XContract类中（仍然扩展了合约接口），并调用BaseContract方法在其中应用合约规则。这已成功测试，并按要求捕获了合同规则。为了获得更多保证，调整了流程以符合合同规则，然后测试交易成功了。
但是，我注意到这显然会导致我们将来拥有大量的BaseContract类文件，但是这些已经到目前为止的测试。
这是实施可靠的项目的好方法，没有可能的前期风险吗？
如果您已经可以在我们的测试中预见到缺点，请提供最好的实现方法的建议。
我需要构建具有可重用/可扩展合同（接口）的cordapp，我决定构建一个可重用的Cordapp平台，该平台将以最少的更新（每个...]满足多个合作需求（按...