代码之家 › 专栏 › 技术社区 › nojevive

在编码框架时,哪种设计选项更好?

implementation abstract-class interface oop

nojevive · 技术社区 · 17 年前

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

例如,我可能有:

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

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

如何确保imystuff和iHelper的实例可用?

一种方法是在接口和框架中创建“getter”方法,并仔细检查返回的空对象。

另一种选择是创建抽象类,实现一个调用(使用策略模式)要实现的接口方法的工厂。但这违背了一个事实,即我首先拥有接口。然后,客户机应该使用抽象类。但是他们可以通过使用接口而不是抽象类来绕过这个问题。因此,我不应该提供接口,而应该只提供抽象类…

那么,你对此有什么看法,务实的做法是什么?

3 回复 | 直到 17 年前

matt b 17 年前

如何确保imystuff和iHelper的实例可用?

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

ChrisLively 17 年前

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

换句话说,从:我的客户将如何处理这个应用程序开始?他们需要如何处理?

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

djna 17 年前

你不能单独用接口来保证它,那里没有行为。

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

可以提供工厂对象:

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它是一个文件,一个副作用稍后关闭了该文件。)然后,您所能做的就是捕获产生的错误条件,在某个地方记录一个错误,并(可能)抛出一个异常。然后,至少开发人员对修复什么有了一个线索。

推荐文章

Samrudh S · 即使值和插入顺序相同,使用equals函数比较映射值也会返回false

1 年前