为什么要用接口（从编程角度）
接口很好大家都知道，但好在哪里却不一定说得出来，至少说得不通俗，或只是人云亦云。我现在所知道的接口好处有以下几点（从编程角度），但我想知道更多更深的好处以及适用场景，而不是为了接口而接口。
假设有一个接口
interface IX
{
int GetMax(int a,bool b);
}

好处：
1.我可以通过往一个IList<IX>立面添加继承了IX接口的对象，然后用foreach(ix in LIST){ix.GetMax(1,true)};因为方法名相同，但如果没用接口我就不能这样调（例如某个类也有GetMax方法，但参数为3个）。
2.继承了IX接口的类，我就知道它具备GetMax方法，但如果没用接口，我必须去看看那个类的GetMax是否真的符合我的调用需求，甚至那个类可能根本就没有GetMax方法，但却有GetMaxValue方法，作用一样只是名字不一样。如果多人开发，用接口减少了很多沟通和解释。
3.修改接口继承类中的实现方法，调用者不需要修改代码。比如很多地方都用了ix.GetMax(1,true)，修改具体接口实现类的方法，我调用的地方不用做修改。（但这里这样解释不准确，因为我如果不用接口，直接在类中改实现方法，只要参数返回值相同，也不用修改调用的地方，请高手说明）
4.可以通过工厂和反射来创建具体的继承IX的实现类，调用者甚至都不知道具体最终调的是哪个实现类的方法。修改实现类的时候，对于调用者做到真正透明。
5.一开始就针对应用定义出需要的接口方法，然后逐步细化，而不会遗漏，而不是一开始就建类，然后不断的补方法，最后弄得这个类很臃肿。
6.多人开发时，我负责A模块开发，要调用GetMax方法，一开始就可以写，尽管负责写GetMax方法的人还没真的写出具体的方法来。但如果不用接口，我要调他的方法，我还要先问他那个获取最大值的方法是不是叫GetMax，是不是返回int，等。
7.在多继承时，接口提供了灵活的机制，我没必要为了统一一个GetMax的方法，就去搞一个抽象类A，万一将来又想统一一个GetName方法，又在抽象类A中加GetName方法？这显然不合理，因为GetName可能更GetMax可能都不是一个范畴的东西，硬要拉在一起，破坏了类的单一职责。
8.接口看起来更简洁。

希望各位告诉我接口还有什么好处？请用具体的场景或代码说明，以上列举如有错也请指出。