依赖注入 – Mark Seemann关于Bastard Injection的矛盾陈述 需要

既然在这里有很多问题，我将首先尝试提供一个关于我的观点的综合，然后根据这个材料明确地回答每个问题。

合成

当我写了the book，我首先试图描述我在野外目睹的模式和反模式。因此，书中的模式和反模式首先是描述性的，只有较小程度的规定性。显然，将它们分为模式和反模式意味着一定程度的判断力:)

Bastard Injection有多个层面的问题：

>软件包依赖关系
>封装
>使用方便

最危险的问题与包依赖关系有关。这是我通过引入“外部默认值”和“本地默认值”这个术语来尝试更有效的概念。外部默认值的问题是它们拖动硬耦合的依赖关系，其中makes (de/re)composition impossible.一个很好的资源，更明确地处理包管理是Agile Principles,Patterns,and Practices。

在封装级别上，这样的代码很难理解：

private readonly ILog log;
public MyConsumer(ILog log)
{
    this.log = log ??LogManager.GetLogger("My");
}

虽然它保护类的不变量，但问题是在这种情况下，null是可接受的输入值。情况并非如此。在上面的例子中，LogManager.GetLogger(“My”)可能只会引入本地缺省值。从这个代码片段，我们无法知道这是否是真的，但是为了参数，让我们假设现在。如果默认的ILog确实是Local Default，则MyConsumer的客户端可以传入null而不是ILog。请记住，封装是关于使客户端轻松使用对象而不了解所有实现细节。这意味着这是客户端所看到的：

public MyConsumer(ILog log)

在C#(和类似的语言)中，可以传递null而不是ILog，它将要编译：

var mc = new MyConsumer(null);

通过上述实现，不仅将编译，而且在运行时也起作用。据Postel’s law，这是件好事，对吧？

不幸的是，它不是。

考虑另一个具有所需依赖关系的类;我们把它称为Repository，只是因为这是一个众所周知的(虽然过度使用)的模式：

private readonly IRepository repository;
public MyOtherConsumer(IRepository repository)
{
    if (repository == null)
        throw new ArgumentNullException("repository");

    this.repository = repository;
}

与封装保持一致，客户端只能看到：

public MyOtherConsumer(IRepository repository)

根据以往的经验，程序员可能会倾向于编写如下代码：

var moc = new MyOtherConsumer(null);

这仍然编译，但在运行时失败！

你如何区分这两个构造函数？

public MyConsumer(ILog log)
public MyOtherConsumer(IRepository repository)

您不能，但目前，您有不一致的行为：在一种情况下，null是一个有效的参数，但在另一种情况下，null将导致运行时异常。这将减少每个客户端程序员在API中具有的信任。一贯是更好的前进方向。

为了使类似MyConsumer的类更容易使用，您必须保持一致。这就是为什么接受null是一个坏主意。一个更好的方法是使用构造函数链接：

private readonly ILog log;

public MyConsumer() : this(LogManager.GetLogger("My")) {}

public MyConsumer(ILog log)
{
    if (log == null)
        throw new ArgumentNullException("log");

    this.log = log;
}

客户现在看到：

public MyConsumer()
public MyConsumer(ILog log)

这与MyOtherConsumer是一致的，因为如果您尝试传递null而不是ILog，您将收到运行时错误。

虽然这在技术上仍然是Bastard Injection，I can live with this design用于本地默认值;事实上，我有时会设计这样的API，因为它是一种众所周知的许多语言成语。

出于许多目的，这是足够好的，但仍然违反了重要的设计原则：

Explicit is better than implicit

虽然构造函数链可以让客户端使用默认的ILog使用MyConsumer，但是没有一个简单的方法来弄清楚ILog的默认实例是什么。有时，这也很重要。

此外，默认构造函数的存在会暴露出一段代码将在Composition Root之外调用该默认构造函数的风险。如果发生这种情况，您已经过早地将对象耦合到对方，一旦你完成了，您不能将它们从组合根中分离。

因此，使用简单构造函数注入的风险较小：

private readonly ILog log;

public MyConsumer(ILog log)
{
    if (log == null)
        throw new ArgumentNullException("log");

    this.log = log;
}

您仍然可以使用默认记录器编写MyConsumer：

var mc = new MyConsumer(LogManager.GetLogger("My"));

如果要使本地默认更容易被发现，您可以将其作为工厂在某处，例如在MyConsumer类本身上：

public static ILog CreateDefaultLog()
{
    return LogManager.GetLogger("My");
}

所有这一切都为回答这个问题中的具体子问题奠定了基础。

1.当默认执行依赖关系是本地默认值时，是否还会发生混蛋注入反模式？

是的，在技术上，它确实，但后果不那么严重。混蛋注射首先是一个描述，使您能够轻松识别它，当你遇到它。

请注意，本书上面的图示描述了如何从Bastard Injection重构;不是如何识别它。

2. [应该]还可以避免使用本地默认值的可选依赖关系[…]

从包依赖的角度来看，你不需要避免这些;他们比较温和

从使用的角度来看，我仍然倾向于避开他们，但这取决于我正在建设什么。

>如果我创建了许多人可以使用的可重用库(例如OSS项目)，我仍然可以选择构造函数链接，以便更容易地开始使用API??。
>如果我正在创建一个仅在特定代码库中使用的类，我倾向于完全避免可选的依赖关系，而是构成组合根目录中的所有内容。

他是否也意味着“外部违约”使并行开发更加困难，而“本地默认”不是？

不，我不如果您有默认值，则默认值必须在使用之前就位;无论是本地还是外国都无关紧要。