個人感覺這篇文章對接口解釋的挺好的！貼出來供大家欣賞一下！
接口
簡單的說接口就是一個契約或者規范.比如遙控器,國家出臺了一個國家遙控器規范,明文要求所有的遙控器廠家都要遵循這個規范,如果不遵循規范就不給3C認證標志,就不允許上市出賣..為什么要這個規范呢?大家在時間生活中會經常碰到,甲廠的遙控器不能遙控乙廠的電視,電視遙控器不能遙控其它電器如空調,冰箱.!原因是什么呢?是各個遙控器都沒有遵循一個規范,電波有長有短,電壓有高有低,導致各自為政,4分5列!
可以想像出國家遙控器標準只是是規定遙控器的一些重要技術指標,比如要發射波應該多長,電壓應該多高,...,但它絕對不會規范出遙控器的材質,形狀,重量和顏色,也是說規范把所有同遙控無關的東西都拋棄了!每個遙控器廠家只要遵循了規范,那么對遙控器可以有任意的詮釋.比如A廠可以用鐵做,牢固無比,B廠可以用紙,可以任意折疊,anyway,不管用什么做,做出什么樣子,只要遵循規范的遙控器就可以遙控所有的電器(當然電器廠家也要遵循一定的規范),甚至可以遙控導彈發射!利害吧,這就是接口的威力.
再詳細點,接口就是一個規范,他和具體的實現無關!接口是規范(虛的),他只是一張紙,也是說在實際的使用中接口只有依托一個實現了它的類的實例,才會有意義,如上面的各個廠家做的遙控器產品.每個實現接口的類(廠家)必需實現接口中所有的功能. 一旦一個類實現了一個接口,就可說一個類和接口捆綁了(這個很重要,做題目的時候會用到)
來個例子
interface 遙控器規范 //國家定義的遙控器規范 ,每個遙控器廠家必需實現(詮釋)它
{
int 波長();
int 電壓();
}
class 甲廠鐵遙控器 : 遙控器規范 //甲廠的遙控器實現(詮釋)了這個規范,它和遙控器規范捆綁了!好,它可以在市場上出售了
{
public int 波長(); //規范上定義的指標
public int 電壓(); //規范上定義的指標
public int 形狀() { 正方形}; //甲廠自己對該產品的詮釋
public int 材質() ( 鐵 }; //甲廠自己對該產品的詮釋
}
class 乙廠紙遙控器 : 遙控器規范 ////甲廠的遙控器實現(詮釋)了這個規范,它和遙控器規范捆綁了!好,它可以在市場上出售了
{
public int 波長(); ////規范上定義的指標
public int 電壓(); //規范上定義的指標
public int 形狀()( 圓形); //甲廠自己對該產品的詮釋,是圓形
public int 材質()( 紙); //甲廠自己對該產品的詮釋,用紙做,好酷!
}
class 電器
{procedure 接收遙控(遙控器規范 ) //電器上,接收遙控指令
{.....
接收(遙控器規范.波長) ;
接收(遙控器規范.電壓);
.....} }
static main()
{
甲廠鐵遙控器 ControlA ; //申明控制器對象
乙廠紙遙控器 ControlB ;
ControlA = new 甲廠鐵遙控器(); //實例化控制器對象,這個時候系統在托管堆中為該對象分配了空間
ControlB = new 乙廠紙遙控器() ;
遙控器規范 ControlInterfaceA = (遙控器規范)遙控器1 ; //把對象實例轉換成一個規范,為什么呢?因為"我家的電器".只能識別遙控器規范,它識別不到具體的遙控器
遙控器規范 ControlInterfaceB = (遙控器規范)遙控器2; //同上
電器 我家的電器 = new 電器();
我家的電器.接收遙控(ControlInterfaceA) //我用甲廠遙控器遙控我家的電器. 注意: 這里的ControlInterfaceA是不能單獨存在的,它必要依賴實現了"遙控器規范"的類的實例"ControlA".道理很簡單,接口是一個指針,不會被分配空間,你就無法使用,只有和一個具體類的實例聯系了,才有了可以活躍空間.
我家的電器.接收遙控(ControlInterfaceB) //我用乙廠遙控器遙控我家的電器
...
//下面是我的的想像,我可以用遙控器來控制導彈發射!
我的導彈.接收遙控(ControlInterfaceA);
我的導彈.接收遙控(ControlInterfaceB);
...
}
--------------------------------------------------------------------
接口的執行
好了,有了接口的概念,再來談c#程序在運行中是如何使用接口的,如何訪問接口函數.具體流程如下
a.當調用一個接口的函數時,系統會去檢查這個接口對應實例是什么?
b.找到這個實例后,再去找這個實例對應的實例類是什么(什么是實例類,參看讀書筆記二)
c.根據這個實例類去檢查該實例類是否和接口發生了捆綁(看是否實現了該接口,冒號后面就是)
d.好!如果實例類實現了該接口(發生了捆綁) ,它就在這個實例類中找函數的定義.然后執行該函數.執行結束.
e.如果沒找到,他就繼續往父類找,直到找到第一個和接口捆綁的父類為止
f.找到后,它再檢查該函數是否是虛擬函數,
g.如果不是,他馬上就執行它 .
h 如果是,麻煩了,系統又要從頭來過,去檢查該實例類的函數是否重載了該函數,...具體過程見(c#讀書筆記2).
例子:
using System;
namespace ConsoleApplication1
{
/// <summary>
/// Class1 的摘要說明。
/// </summary>
public interface I
{
void Func();
}
class A :I
{
public virtual void Func()
{
Console.WriteLine("FuncA");
}
}
class B : A , I //注意這里的意思?
{
public override void Func() { Console.WriteLine("FuncB");}
}
class C : A
{
public override void Func() { Console.WriteLine("FuncC");}
}
class Class1
{
/// <summary>
/// 應用程序的主入口點。
/// </summary>
[STAThread]
static void Main()
{
I a = new A() ; //申明了接口a,并馬上和一個類的實例發生關系了
I b = new B() ; //申明了接口b,并馬上和一個類的實例發生關系了
I c = new C() ; //申明了接口c,并馬上和一個類的實例發生關系了
a.Func() ; //檢查a的實例A, 發現A和接口I捆綁了,所以執行A的函數Func ,結果: FuncA
b.Func() ; //檢查b的實例B, 發現B和接口I捆綁了,所以執行B的函數Func ,結果: FuncB
c.Func() ; //家常c的實例C,發現其沒有和接口I捆綁,系統繼續找它的父類. 發現A和I捆綁了,他就去找函數A,發現A是虛擬函數,系統又從頭來找類的實例C,發現C重載(override)了Func,好了,馬上執行該函數. 結果是FuncC;
Console.ReadLine();
}
}
}