你的同学说的大部分内容是正确的，但有个关键前提需要补充——这种做法的核心是面向抽象编程，背后对应几个经典的面向对象设计原则，我来给你拆解清楚：

一、返回类型：尽可能宽泛（优先用父类/接口） #

这个建议是完全正确的，核心目的是降低调用方与具体实现的耦合度，提升代码的灵活性和可维护性。

举个例子：如果你的函数返回ArrayList<String>，调用方很可能会直接依赖ArrayList的特有方法（比如ensureCapacity()、trimToSize()）。哪天你因为性能需求想把实现改成LinkedList，调用方的代码就会直接报错，因为LinkedList没有这些方法。

但如果返回List<String>，调用方只能使用List接口定义的通用方法（比如add()、get()、size()），你后续切换任何List的实现类（LinkedList、CopyOnWriteArrayList等）都不会影响调用方的代码。

这完全符合面向接口编程的思想，也和里氏替换原则（LSP） 一致：父类/接口可以被任何子类替换，而不会影响程序的正确性。

二、参数类型：不是“尽可能具体”，而是“按需选择” #

你同学的这个说法需要修正——参数类型的选择不是越具体越好，而是根据函数的实际职责和依赖来决定：

• 如果你的排序函数确实需要用到ArrayList的特有方法（比如底层数组的快速随机访问来优化排序逻辑），那参数用ArrayList是合理的；
• 但如果排序逻辑只依赖List接口的通用方法（比如遍历、获取元素），那应该用List作为参数，这样你的排序函数可以兼容所有List实现类，复用性会强很多。

举两个代码对比的例子：

// 仅当必须依赖ArrayList特有方法时使用具体类型
public void optimizeAndSort(ArrayList<Integer> list) {
    list.trimToSize(); // 只有ArrayList有这个方法
    Collections.sort(list);
}

// 排序逻辑仅依赖List通用方法时，用接口更灵活
public void sortAnyList(List<Integer> list) {
    Collections.sort(list); // 所有List实现都支持这个排序
}

三、背后的核心设计原则 #

这种选择逻辑本质上是以下几个面向对象原则的体现：

• 依赖倒置原则（DIP）：依赖于抽象，而不是具体实现。返回和参数优先用抽象（接口/父类），可以减少代码间的耦合；
• 里氏替换原则（LSP）：确保父类/接口的实例可以被子类实例替换，程序行为不受影响；
• 接口隔离原则（ISP）：如果参数用过于宽泛的类型，但函数只用到其中一小部分方法，可能会违反这个原则——但实际中还是优先以函数的实际需求为核心。

总结 #

你的同学的思路方向是对的，但参数类型的选择要避免“为了具体而具体”：

• 返回类型：尽量用最宽泛的抽象类型（接口/父类），隐藏具体实现细节，给未来的修改留足空间；
• 参数类型：如果函数不需要依赖具体实现的特有功能，就用抽象类型；只有当必须依赖时，才使用具体类型。

内容的提问来源于stack exchange，提问作者R Ree