但是，就以上示例而言，当 Rectangle 接口的 getBounds 方法返回一个 Rectangle 时，您可能不知道使用 Rectangular 接口会有什么实际的好处；也就是说，如果我们知道我们要传入的对象在被请求时能返回 Rectangle；为什么不传入 Rectangle 类型而要传入接口类型呢？最重要的原因与集合有关。假定有这样一个方法：
static public boolean areAnyOverlapping(Collection rects) {...}
该方法旨在判断给定集合中的 rectangular 对象是否有重叠。接下来，在方法体中，当您依次处理集合中的每个对象时，如果无法将对象转换为诸如 Rectangular 这样的接口类型，如何才能访问那个对象的 rectangle 呢？唯一的选择是将对象转换为特定的类类型（我们已知该类中有一个方法能提供 rectangle），这意味着该方法必须事先知道它要对何种类类型进行操作，因此重用它时只能使用这些类型。这就是这一步首先要避免的问题！
第三步：选择耦合性较小的输入参数接口类型
在执行第二步时，应该选择何种接口类型来替代给定的类类型呢？答案是：能充分描述过程对参数的要求且累赘最少的任何接口。参数对象要实现的接口越小，任一特定类能实现该接口的机会就越大 -- 因而其对象可用作该参数的类的数量也就越多。很容易看出，如果您有如下这样一个方法：
static public boolean areOverlapping(Window window1, Window window2) {...}
该方法旨在判断两个（假定为 rectangular）窗口是否重叠，如果该方法仅要求它的两个参数提供它们各自的 rectangular 坐标，则最好简化这两个参数的类型以反映这一事实：
static public boolean areOverlapping(Rectangular rect1, Rectangular rect2) {...}
以上代码假定前面的 Window 类型对象也能实现 Rectangular。现在您就可以重用任何 rectangular 对象的第一个方法中所包含的功能。
您可能有过多次这样的经历，即充分指定了参数要求的可用接口包含过多不必要的方法。碰到这种情况时，您就应在全局名称空间中定义一个新的公共接口，以便其他可能面临同样窘境的方法重用这个接口。
您也可能有过多次这样的经历，即最好创建一个独特的接口来指定单个过程对一个参数的要求。您所创建的接口只会用于那个参数。当您希望将参