4

The Pragmatic Programmer中第 143 页的代码片段如下：

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());
    }
}
4

2 回答 2

4

与对象公开的API相比，如何构造对象的创建是一个单独的问题。

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

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

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

于 2010-03-19T08:12:23.633 回答
2

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

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

干杯

尼克

于 2010-03-19T07:41:21.013 回答