日期:2014-05-17  浏览次数:20477 次

为什么要用接口(从编程角度)
接口很好大家都知道,但好在哪里却不一定说得出来,至少说得不通俗,或只是人云亦云。我现在所知道的接口好处有以下几点(从编程角度),但我想知道更多更深的好处以及适用场景,而不是为了接口而接口。
假设有一个接口
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.接口看起来更简洁。

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