Question

我正在编写一个框架（在Java中，但问题是通用的），其中我将为客户端提供一组接口来实现。框架中的函数将依赖于如何构造实现类，也就是说，依赖于那些实现来提供其他接口实例。

例如我可能有：

Interface IContribution {
   public IMyStuff getMyStuff();
   public IHelper getHelper();
}

Interface IMyStuff {
     public void doSomeMethod(IHelper helper);
}

如何确保IMyStuff和IHelper的这些实例可用？

一种方法是在界面中创建'getter'方法，并在我的框架中仔细检查返回的null对象。

另一种选择是创建实现工厂的抽象类，该工厂调用（使用策略模式）要实现的接口方法。但是，这就是我首先拥有界面的事实。然后客户端应该使用抽象类。但他们可以通过使用接口而不是抽象类来绕过这一点。因此，我不应该提供接口，而只提供抽象类......

那么，您对此有何看法，对此有何实际意义？

Answer 1

如何确保IMyStuff和IHelper的这些实例可用？

如果客户端负责自己实现接口和类，我会说他们有责任确保这些实例可用 - 我不会把自己放在我自己的代码中。

Answer 2

为了构建一个好的框架，您需要同时围绕它构建一个应用程序。通过这种方式，您将了解并了解客户在被强加给他们之前所忍受的痛苦。

换句话说，从以下开始：我的客户将如何使用此应用程序？他们如何与之合作？

你会立即意识到，从他们的角度来看，最简单的方法是最好的。

Answer 3

你无法单独使用Interfaces来确保它，也没有行为。

我同意框架中防御性编程的哲学，帮助开发人员避免犯错误。

您可以提供工厂对象：

public class MyPoliceman {
    public IContribution makeContributor( IMyStuff stuffer, IHelper helper)
                    throws BadAssociatesException {

     // check validity of stuffer and helper here, throw exceptions if null
    }
}

然后至少我们可以检查空值等。

有些人认为通常可以给开发者提供帮助。在某些情况下，您可以做的最好的事情就是捕获错误并报告它们。例如，在这里，一个非常精细的IHelper可以传递给你的工厂，但是后来对这个类的操作可能会使它无法实现。（例如，Image它是一个文件，副作用后来关闭了文件。）然后你所能做的就是捕获产生的错误条件，在某处记录错误并（可能）抛出异常。然后至少开发人员有一个关于解决问题的线索。

哪种设计选项更适合用于编码框架？

3 个答案: