通常，您应该更喜欢接口而不是具体的类。沿着这些思路，如果可以避免使用new运算符(就像在新的ArrayList示例中那样始终需要使用具体类型)，那就更好了。
所有这些都与管理代码中的依赖关系有关。最好仅依赖于高度抽象的事物(例如接口)，因为它们也往往非常稳定(请参阅/resources/articles/stability.pdf)。因为它们没有代码，所以仅当API更改时才需要更改它们，换句话说，当您希望该接口向世界展示不同的行为(即设计更改)时。
另一方面，课程总是在变化。依赖于类的代码不在乎它如何执行其工作，只要API的输入和输出不变，调用者就不必在意。
您应该根据开放式原则(参见/resources/articles/ocp.pdf)努力确定类的行为，这样即使添加功能也无需更改现有接口，您可以只指定一个新的子接口。
避免使用新运算符的旧方法是使用Abstract Factory模式，但这有其自身的一系列问题。更好的方法是使用Guice之类的工具进行依赖项注入，而更喜欢构造函数注入。在开始使用依赖项注入之前，请确保您了解依赖关系反转原理(请参阅/resources/articles/dip.pdf)。我见过很多人注入不合适的依赖项，然后抱怨该工具没有帮助他们……这不会使您成为一名优秀的程序员，您仍然必须适当地使用它。
示例：您正在编写一个程序来帮助学生学习物理。在该程序中，学生可以将球置于各种物理场景中，并观察其行为：将枪从悬崖上的大炮中射出，将其置于水下，深空等。问题：您想包含一些关于球的沉重性的信息Ball API中的球...您应该包含getMass()方法还是getWeight()方法？
重量取决于碰巧碰到的球的环境。调用方可以方便地调用一个方法并在碰巧碰到的地方获取球的重量，但是您如何编写此方法呢？每个球实例必须不断跟踪其位置以及当前的重力常数是多少。因此，您应该首选getMass()，因为质量是球的固有属性，并且不依赖于其环境。
等待，如果您只是使用getWeight(Environment)怎么办？这样，ball实例就可以从环境中获取当前g并继续进行……更好的是，您可以使用Guice将环境注入到Ball的构造函数中！我经常看到这种类型的滥用，最终人们指责Guice无法像他们希望的那样无缝地处理依赖项注入。
这里的问题不是Guice，而是Ball API设计。重量不是球的内在属性，因此也不是应该从球上获取的属性。相反，Ball应该使用getMass()方法实现MassiveObject接口，而Environment应该具有一个名为getWeightOf(MassiveObject)的方法。环境固有的是其自身的引力常数，因此它要好得多。而且Environment现在仅依赖于一个简单的接口MassiveObject ...，但是它的工作是包含对象，所以这是应该的。
