oop - 具有可选功能的框架接口(interface)的接口(interface)隔离原则

Question

我正在设计一个身份验证框架。我需要框架的用户来实现数据访问逻辑，因为它不是框架的主要目的，我希望允许多种数据访问方法(SQL、NoSQL、缓存等)。我不在我的框架内实现它。我的框架通过一个名为 的接口(interface)使用此逻辑。用户商店 但问题是，我的界面中有某些方法仅在某些功能处于事件状态时才使用，否则不会使用。例如框架将尝试通过 访问两个因素信息。获取TwoFactorInfo 仅当启用了两因素身份验证时才使用该方法。
我的问题是关于接口(interface)隔离原则。是否可以保留界面原样并在文档中说明用户需要实现 获取TwoFactorInfo 仅当用户想要使用两因素身份验证并抛出 NotImplementedException 除此以外？或者我应该为每个可选功能分离接口(interface)并在文档中解释用户应该实现该接口(interface)并将其注册给服务提供商以便能够使用该功能？第二种方法的一个问题是，当将实现这些接口(interface)的服务注入(inject)到构造函数时，我需要检查这些功能是否处于事件状态，否则我会收到错误，因为服务未注册并且我正在尝试从服务提供商访问这些服务。这导致我的框架类更加复杂。
处理这个问题的最佳方法是什么？

Answer 1

您建议的两种方法都存在实际问题，但计划让客户抛出 NotImplementedException更糟。
让我们来看看它们:
选项1

leave the interface as it is and explain in the documentation that user needs to implement GetTwoFactorInfo only if user wants to use two factor authentication and throw NotImplementedException otherwise

好吧，这可能适用于您今天遇到的问题，但软件设计是关于您明天将遇到的问题。如果您为 future 版本的框架添加对不同身份验证方法的支持会发生什么？如果您遵循此模式，那么您将向 IUserStore 添加新方法...但这会破坏现有客户，因为他们不会实现它们!
您可以通过为抛出异常的新方法提供默认实现来解决某些语言中的这个特定问题，但这违背了首先定义接口(interface)的大部分目的——类型系统不再告诉客户他必须做什么实现。
此外，此模式仅适用于预先存在的接口(interface)。如果您添加一个新的身份验证方法，要求客户端实现一个新接口(interface)，那么您将重新考虑类似于您的第二个选项，那么如果版本控制策略，您将有不一致的组合。伊克。
选项 2

separate interface for each optional feature and explain in the documentation user should implement and register this interface to service provider to be able to use that feature

这要好得多，但也不是很好，因为它引入了框架的客户端必须遵循的隐藏规则。找出这些规则的所有方法都令人沮丧——阅读文档、解决错误等。
这是很多依赖注入(inject)系统中的一个常见问题，虽然很多人似乎并不介意，但是随着隐藏规则的交互系统积累，事情变得非常复杂。
选项 3
我不知道您现在如何启用此 2 因素功能，但我建议您让您的客户通过调用将隐含依赖项作为参数的方法来启用此功能，例如

void enable2FactorAuth(I2FactorInfoStore store)

然后所有的潜规则都消失了。您的系统确保您无法启用该功能，除非您已实现所需的接口(interface)。简单的。
如果您认为您将失去在没有编程的情况下配置产品的能力，那么我想提醒您，您没有该功能。正如您所说，客户端必须编写一些代码才能使用 2 因素身份验证。他们必须实现商店。要求他们调用一个方法来启用它只会改进这个代码，因为现在很明显为什么他们必须首先实现那个商店。