1)Here他说，只有当我们使用Foreign Default时，才会发生混蛋注射。
但是在他的书中，第148页的图示显示，当依赖关系的默认实现是Foreign Default或Local Default时，会发生Bastard注入：
那么当默认执行依赖关系是一个本地默认值时，Bastard Injection反模式也会发生吗？
2)Here(也在他的书中)他指出，一个类有一个可选的依赖关系，只要这个依赖关系的默认实现是一个很好的局部默认：
但在下一个article，他似乎反对有可选的依赖关系，即使默认实现是一个本地默认：
06000
In terms of encapsulation,the main problem with such an approach is
that it seems like the MyConsumer class can’t really make up its mind
whether or not it controls the creation of its log dependency. While
this is a simplified example,this Could become a problem if the ILog
instance returned by LogManager wraps an unmanaged resource which
should be disposed when it’s no longer needed.
在默认执行依赖关系是本地的时候，他上述摘录中的论证也是有效的吗？如果是这样，那么还应避免使用本地缺省值的可选依赖关系？
3)
PG。 147：
The main problem with Bastard Injection is its use of a FOREIGN
DEFAULT …,we can no longer freely reuse the class because it drags
along a dependency we may not want. It also becomes more difficult to
do parallel development because the class depends strongly on its
DEPENDENCY.
外部默认是一个依赖关系的实现，它用作默认值，并且在不同于其消费者的程序集中定义。因此，在外来违约方面，消费者集会也将拖累依赖关系的集会。
他是否也意味着“外部违约”使并行开发更加困难，而“本地默认”不是？如果他是这样，那么这是没有意义的，因为我会假设并行开发困难的原因并不在于消费者的大会很难提及依赖组织，而是消费类依赖于具体实现的事实依赖？
谢谢
合成
当我写了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。
>如果我正在创建一个仅在特定代码库中使用的类，我倾向于完全避免可选的依赖关系，而是构成组合根目录中的所有内容。
他是否也意味着“外部违约”使并行开发更加困难，而“本地默认”不是？
