Question

此问题的变化已被问及here，并且在较小程度上here，但我不认为这是一个重复的问题。我有一个类似于第一个链接中提出的问题的场景：我有一个我正在使用DI的核心库。对于许多类，我期望调用应用程序将提供这些类所期望的接口的实现，因此可以合理地假设调用应用程序将正确设置其容器（如果有的话）。

我遇到的问题是我设置了几个外墙。这些外观所依赖的接口是在我的库中实现的，并且它们不应该是调用应用程序提供的东西。在第一个链接中，Mark Seemann建议使用高度可发现的外观来封装依赖关系组合，如果API对于新手用户来说是复杂的。虽然我认为API没有任何过于复杂的问题，但我的目标是让调用应用程序能够执行类似的操作（了解Widget具有内部依赖性）：

var foo = new Widget();

如果我使用Mark关于外观的想法来返回Widget期望的实现，那么Widget的实现可能看起来像这样：

public class Widget()
{
    public Widget() : this(DependencyFacade.SystemOneDep()) { }
    internal Widget(ISystemOne sysOne)
    {
      //Do work
    }
}

SystemOneDep()调用只返回ISystemOne的实现。当然这可以工作，但（我可能会过度思考这个）这对我来说有点气味，因为我现在已经加入了DependencyFacade类（内部可能是DependencyFacade正在调用实际返回实例而不是简单地新建对象的工厂在门面）。可以理解的是，在某些时候，某些事情需要了解接口的具体实现并将其提供给消费者，因此这可能是正确的方法。

这里真正的问题是：是否有更好的方法来实现预期的结果，或者使用外观是“最佳”方法来实现结果？

使用DI与立面

0 个答案: