編碼一兩年,html
我走過了字段,程序員
我跑過了類,app
卻翻不過方法。(不能靈活使用方法吧)this
(寫這篇博客全程聽將夜中《永夜》歌曲寫完的,一鼓作氣,安利一下)編碼
咱們在編碼中,常常搗鼓來搗鼓去的無非就是 「 字段,方法 ,類這三種。像字段,類的使用(引用)很簡單,可是,方法的使用(引用,傳遞)貌似,有點「模糊」不清。甚至有些初學懼怕委託,懼怕見到delegate這個關鍵字。spa
可是通常稍微成熟點的大佬的方法都是充滿delegate的,是否是,哈哈哈。所以,你不得不去使用。關於方法引用的好處嘛,一句話,逼格很高,你必須學會去使用,這是上升爲中級程序員必須會的。(代碼可讀性,耦合性等好處大大有)翻譯
那麼,如今若是讓我來設計如何傳遞(引用)方法,我是如何設計的。設計
大概就是能夠有/無返回參數,有傳入參數,傳入參數數量不必定,類型不必定。code
即如圖htm
由於如上圖可知,方法類型是很不明確的,那麼咱們須要明確好方法。這裏用TOM(type of method)關鍵字做爲咱們明確方法類型的關鍵字。
public TOM void tom1();//tom1是無返回值,無傳入參數的方法類型 public TOM void tom2(string str);//tom2是i無返回值,有一個string類型參數 public TOM int tom3(int num, string str);//tom3是int型返回值,有一個int傳入參數+一個string型傳入參數
咱們用這樣的規則(這個規則,是須要死記),就能夠明肯定義出任意咱們 想要的具體方法類型。(這應該很容易理解的吧)
由上述2可知,有三種例子類型。很簡單
public TOM void tom1();//tom1是無返回值,無傳入參數的方法類型 public TOM void tom2(string str);//tom2是i無返回值,有一個string類型參數 public TOM int tom3(int num, string str);//tom3是int型返回值,有一個int傳入參數+一個string型傳入參數 static void Main(string[] args) { tom1 t1 = Test1; t1(); tom2 t2 = Test2; tom2 t2_2 = Test2_2; t2("tttt22222"); t2_2("tttt22222"); tom3 t3 = Test3; int num3 = t3(1, "3333tt"); Console.Read(); } static void Test1() { Console.WriteLine("test1"); } static void Test2(string str) { Console.WriteLine("test2:"+str); } static void Test2_2(string str) { Console.WriteLine("test_2:"+str); } static int Test3(int num,string str) { Console.WriteLine("THis is Test3:"+num.ToString()+str); return num + 1; }
(上述TOM 改成delegate ,便可編譯成功,真的吐槽爲什麼中文翻譯爲委託,真的很拗口,不過,真的很很差定義吧....我也想不到更好的兩個字能夠歸納的)
上述TOM即爲委託(delegate),爲啥我不直接說delegate,直接說delegate,這個東西,真的很難理解。記住,TOM(type of method),方法的類型,再準確的說是定義方法的類型的類型。TOM tom1,這個tom1,則爲某具體方法的類型的類型。
接下來用delegate來寫吧,可是你心裏仍是要記住type of method(方法的類型)。
(其實官方講,我是沒啥好講的,直接推薦兩篇博客吧 https://www.cnblogs.com/hushzhang/p/5901052.html)
由於最近本身墮入愛河,舉個談戀愛的例子吧。
1)男女戀愛分手用例。
需求:女孩紙開心值下降到必定,就會提出分手。或者男孩紙比較渣,男孩紙提出分手。提出分手,
女孩紙會哭泣;男孩紙會變爲單身狗。
步驟:
①首先,先定義一個無返回值,無傳入參數的委託,SeparateDelegate。
public delegate void SeparateDelegate();
②聲明一個女孩紙類,聲明一個SeparateDelegate委託的實例mSeparateDel,並在初始化中給mSeparateDel
賦初始(註冊)分手回調;女孩紙開心值低於1的時候,觸發分手。(女孩紙被動分手,不開心纔會分手,由於女孩紙不開心纔會分手嘛。)
class GirlFriend { public SeparateDelegate mSeparateDel; public string mName { get; set; } private int happyNum; public int mHappyNum { get { return happyNum; } set { happyNum = value; if(happyNum<1) { Console.WriteLine("我女孩紙,決定了,分手,開始觸發分手:"); mSeparateDel(); } } } public GirlFriend(string name) { mName = name; mHappyNum = 80; //剛開始作女友確定很開心嘛 mSeparateDel = SeparateCallBack; } void SeparateCallBack() { Console.WriteLine("我是女孩子,分手了,我大哭..."); } }
③聲明一個男孩紙類,能夠將女孩紙設爲男孩紙女友,並繼續註冊女孩紙提出分手可觸發的回調;男孩紙能夠提出分手。(渣男就是
不同,分手無理由,各類理由,花心啊,膩了,遇到更漂亮的小姐姐等等,跟開不開心無關係,哈哈哈...)
class BoyFriend { public string name { get; private set; } public GirlFriend mGirlFriend; public BoyFriend(string name,GirlFriend girl) { this.name = name; this.mGirlFriend = girl; girl.mSeparateDel += RemoveGirlFriend; } void RemoveGirlFriend() { if (this.mGirlFriend != null) { this.mGirlFriend = null; } Console.WriteLine("做爲男孩紙,很難受,男人不哭,迴歸單身狗"); } public void PresentSeparate() { this.mGirlFriend.mSeparateDel(); } }
④實際運行。(保證代碼能夠跑起來)
class Program { static void Main(string[] args) { GirlFriend gl = new GirlFriend("XiaoHong Li"); //固然先有女友 BoyFriend mySelf = new BoyFriend("Jack Deng",gl);//纔有男友 gl.mHappyNum = 0;//開心值下降,女孩紙自身觸發分手 // mySelf.PresentSeparate(); //男孩紙主動觸發分手 Console.Read(); } }
能夠看到上述女孩紙自身調用和男孩紙調用出發均可以調用如下運行結果(紅框中的,分手能夠觸發的回調)。
仍是繼續上述用例來講,由於上述用例,觸發分手,男孩子和女孩紙均可以觸發分手。
需求:如今由於當今社會是女權主義偏多了,再加上程序員們的忠貞,保證不會觸發分手,如今就是要求,設計如此:男孩紙不能觸發分手,
只能由女孩紙觸發。該怎麼作哦。
分析:
由於女生的委託實例 mSeparateDel是public的,固然是渣男想調就能調,甚至誰想調,任什麼時候候都能調。那咱們把public改成private。
但是矛盾來了,男孩紙也不能註冊分手回調了(致使的問題是女孩說分手,男孩不知道,沒影響),這樣作確定是不行的。
解決:
這時候,事件出來了。爲了解決上述問題,只要
// public SeparateDelegate mSeparateDel; public event SeparateDelegate mSeparateDel;
改爲這樣,就好了,增長event關鍵字。就是事件了。
結果:
編譯報錯了。渣男不能調用了,可是仍是能夠+=,註冊,是沒有問題的。(事件的做用及區別)
個人理解是,事件與委託的區別:
事件是一種特殊的委託,事件∈委託,委託∉事件,即事件是委託的子集。
事件是對委託的一種封裝,相似於屬性是對字段的封裝。
總結:事件就是巧妙的讓渣男再也不說分手。強化女權,只能讓女子說分手,而又能影響到男子。
說來慚愧,筆者如今三年Unity經驗,對於委託事件的理解,也是最近纔算徹底參透的吧。以前真的是看過無數篇文章,一直都是含糊不清,也看了網上
不少關於委託事件的博客,一直真的是,愈來愈不模糊吧,直至如今,我想,我這一次,真的應該是完全理解了。(若有不合,歡迎指正。)這其中,滿是本身的
理解,如題所述,通俗說,沒有太多的官話。
2018年12月31日完,終於趕在2018年最後一天,寫出一篇本身滿意的帖子,滿是本身的理解。