实用程序员练习 26答案

【问题标题】：Exercise 26 of The Pragmatic Programmer实用程序员练习 26
【发布时间】：2010-03-19 07:22:51
【问题描述】：

在第 143 页的The Pragmatic Programmer 中有一个代码 sn-p：

public class Colada {
    private Blender myBlender;
    private Vector myStuff;

    public Colada() {
        myBlender = new Blender();
        myStuff = new Vector();
    }
    private doSomething() {
        myBlender.addIngredients(myStuff.elements());
    }
}

这符合得墨忒耳定律/最少知识原则。

使用依赖注入替换它是否更可取，是否有任何警告？

public class Colada throws IllegalArgumentException {
    private Blender myBlender;
    private Vector myStuff;

    public Colada(Blender blender, Vector stuff) {
        if (null == blender) {
            throw new IllegalArgumentException()
        } else {
            myBlender = blender;
        }
        if (null == stuff) {
            throw new IllegalArgumentException()
        } else {
           myStuff = stuff;
        }
    }

    public static Colada createDefaultInstance() {   
        Blender blender = new Blender();
        Vector stuff = new Vector();

        return new Colada(blender, stuff);
    }

    private doSomething() {
        myBlender.addIngredients(myStuff.elements());
    }
}

【问题讨论】：

这不是滥用?:吗？你不觉得写成 if-else 语句会更易读吗？
称为getInstance 的方法通常与单例有关。我认为createDefaultInstance 更合适。干杯
我喜欢 IllegalArgumetnExceptions 在 if 中单独存在，而不在 else 中。更好地显示意图。

标签： java dependency-injection law-of-demeter

【解决方案1】：

您如何构造对象的创建与它所公开的 API 是一个单独的问题。

得墨忒耳法则说明了类的 API，而不是它们的构造方式，所以我认为 构造函数注入 和得墨忒耳法则之间没有冲突。

也就是说，一旦您决定使用依赖注入，在创建对象时应该小心避免歧义。如果您继续提供无参数构造函数或静态工厂方法，人们可能会使用它而不是让外部调用者组成依赖层次结构。

每次开发人员使用工厂方法（或无参数构造函数）意外破坏依赖层次时，他们都会在此时引入紧密耦合。当您决定使用 DI 时，您可以始终如一地从中获益。

【讨论】：

【解决方案2】：

public getInstance()，不应该是“public static Colada getInstance()”吗？

在我的世界里两者都很好，第一个更易读，第二个更动态。但是它们都没有暗示 myBlender 和 myStuff 是属性，因此很难理解为什么你更喜欢它是动态的。但如果这就是你想要的，它看起来没问题。不过，我只创建了两个构造函数，而不是 getInstance，一个像第一个示例一样没有参数，一个像第二个示例一样有两个

干杯

尼克

【讨论】：

修复了静态工厂方法声明。回复：“很难理解为什么你更喜欢动态的。” => 这是对执行单元测试能力的习惯。