哪个设计选项更适合用于编写框架？答案

【问题标题】：Which design option is better to use in coding a framework?哪个设计选项更适合用于编写框架？
【发布时间】：2010-11-05 23:05:09
【问题描述】：

我正在编写一个框架（在 Java 中，但问题是通用的），我将在其中提供一组接口供客户端实现。框架中的功能将依赖于实现类的构造方式，也就是说，它们依赖于这些实现来提供其他接口实例。

例如我可能有：

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

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

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

一种方法是在接口中创建“getter”方法，然后在我的框架中煞费苦心地检查返回的空对象。

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

那么，您对此有何想法，对此有何务实的做法？

【问题讨论】：

危险威尔罗宾逊，危险：建筑师宇航员在前面。

标签： oop interface abstract-class implementation

【解决方案1】：

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

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

【讨论】：

任何框架都应该存在以提供工具供程序员使用，但是最终取决于程序员使用该工具并适当地实现该工具。好的文档真的是你所需要的。
没错。从您的问题来看，您听起来像是在与您的用户进行某种战斗-“如果我这样做，他们可以规避它并这样做……”-请确保如果用户决定滥用您的框架，他们会成功的。但是您不是为滥用用户编写框架，而是为（希望）希望事情正常工作的用户编写框架。仅记录接口方法必须返回有效对象这一事实就足够了，即使这样也可能有点多余。您可以检查空值以更好地适应错误，但实际上仅此而已。
好的，对，所以不能保证。在这里和那里的智能检查应该会发现最严重的错误，但其余的归结为拥有良好的文档。

【解决方案2】：

为了构建一个好的框架，您需要同时围绕它构建一个应用程序。这样一来，您就会知道并理解客户在被强加于他们之前所承受的痛苦。

换句话说，从以下问题开始：我的客户将如何使用此应用程序？他们需要如何使用它？

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

【讨论】：

谢谢，很棒的“最佳实践”建议。

【解决方案3】：

你不能单独使用接口来确保它，那里没有任何行为。

我同意Framework中防御性编程的理念，帮助开发者避免犯错。

你可以提供一个工厂对象：

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

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

那么至少我们可以检查空值等。

经过一番思考，通常可以为开发人员提供帮助。在某些情况下，您能做的最好的事情就是捕获错误并谨慎地报告它们。例如在这里，可以将一个完美的 IHelper 传递给您的工厂，但稍后对该类的操作可能会使其无法使用。（例如，图像它是一个文件，后来有副作用关闭了该文件。）然后您所能做的就是捕获产生的错误条件，在某处记录错误并（可能）抛出异常。然后至少开发人员知道要修复什么。

【讨论】：