反射機制（Reflection）
何為反射
反射是光在兩種物質分界面上改變傳播方向又返回原來物質中的現象
反射是生物體對外界刺激做出應激行為的過程，根據產生的原因分為條件反射和非條件反射等，典型的實驗案例包括巴甫洛夫的狗……
反射是一些面向對象程序設計語言提供的針對類對象元數據（Metadata）的一種訪問機制。
元……數據？？什麼高深莫測的武功？？
啊，誠然，一旦涉及到“元XXX”事情通常就開始變得無比抽象，以至於我不禁念叨起那句訣
太極生兩儀，兩儀生四象，四象生八卦……
不過元數據這個概念在數據庫里還是比較常見的，比如，某個關係型數據庫里有張表：
水果
編號 名字 數量 1 蘋果 6 2 香蕉 3 3 梨 5 4 橘子 3 5 菠蘿 2
數據，就是存在表裡的一條一條的記錄，(1,蘋果,6)，（3,梨,5）都是數據，那麼，元數據就是凌駕於這些數據之上的用於描述數據的數據，對於這張表而言，也就是這張表的表頭（關係數據理論里稱之為關係模式）：(編號,名稱,數據)。
划重點
元數據（Metadata）：用於描述數據的數據
好像有些明朗了，但那關面向對象什麼事呢
眾所周知，類（Class）是面向對象的一個重要概念，儘管，針對於數據庫來說，對象模型和關係模型是不同的概念（上文提到的是關係模型的一個例子），但是，對象模型中的對象和關係模型中的關係，其級別是等同的。
關係……又對象……越來越聽不懂了
好吧，我們先把關係放在一邊，我們只把上邊的東西看做一張表。
難道你就沒有把它改寫成如下形式的衝動嗎？？
public class Fruit
{
public int no;
public string name;
public int count;
public Fruit(int no, string name, int count)
{
// ...
}
}好了，上面的類定義的語義就是
有這樣一類東西，我們稱呼這類東西為水果，結構如下……
那麼，這樣一來，我們就可以定義一個no為9，name叫做“西瓜”，count為5的一個對象，這個對象具有具體的數據。
而上面的類定義代碼，包含的就是這個類的元數據。
說的再直白點吧
以人為例，數據注重的是這人的臉長啥樣，而元數據注重的是這人有沒有臉（好像不太對……）
好吧差不多了解了，但元數據和反射有什麼關係呢
反射是一些面向對象程序設計語言提供的針對類對象元數據（Metadata）的一種訪問機制。
本文一開始就說了，罰站20年！
不過在此之前先解釋一件事，元數據在哪。
任何一個面向對象的程序設計語言，其類類型都具備一個元數據的存儲，至少程序會使用這個元數據能夠動態地構造此類的對象。但不同的語言機制不同，比如C++這種的，因為直接和系統進行愉♂快的互♂動，因此元數據就直接使用系統的內存地址了，這種數據使用是很不直觀的，同時也不使用任何託管機製做後援（巨硬魔改的C++/CLI不在討論範圍內），因此這種貼近底層的語言不支持反射機制，雖然可以通過強行向程序代碼中通過工廠類模式強行注入可讀的元信息（方法參見這位大佬的文章）。
但是，正如前面所說的，如果元數據在託管編譯或解釋的狀態下會保留一份可讀的版本，這是提供給解釋器或者託管平台用的，當然，這種情況下語言一般會提供一個較為完善的元數據訪問機制，這就是反射。這類語言典型的代表就是C#（.NET託管）、Java（JVM虛擬機）、Python（解釋器提供）等。
那……反射是如何運作的呢？？
反射嘛。那還不容易，拿個鏡子就可以了呀！
或者用羊角錘以偷襲的方式砸膝蓋什麼的也是很容易的呀！
不過這麼說來，拿羊角錘偷襲鏡子豈不是更棒！！
正如之前所說，反射機制是對類的元數據的獲取和操縱，因此，一個重要的前提就是：
這個程序設計語言的運作機制當中，類的元數據必須是可見的，如果可讀的話那更好
只有當類的元數據是可見的，反射機制才有訪問它們的可能，但是元數據的可讀性會決定反射機制訪問它們的難易程度。
這裏補充一句，有人會說，在使用IDE或者代碼編輯器的時候，我們寫object.property這種訪問方式的時候編譯器不就直接告訴我們了么？？
關於這一點，這裏暫時只說一個前提：
反射機制的實際動作是聚焦於運行時（Runtime）的。
在程序代碼編譯之前我們恣意地書寫這MyObject.id.hashCode.getFlush().balabala的時候，這是預編譯的過程，預編譯的時候當然這些元數據都是以字面形式給出的（因為你的代碼里寫了這個類的定義），你可以非常愉悅地Ctrl+C Ctrl+V或者享受着IntelliSense帶給你的N倍快樂，這個時候再談反射就沒什麼意義了，因此，反射機制訪問元數據都是在編譯后的運行時發生的。
明明都是面向對象，為什麼偏偏C++不支持這個東西呢
以C++為例，這些元數據是否可見？答案是肯定的，那為什麼不支持反射機制呢，因為這些元數據是以指針的方式給出的，指針在已編譯的C++程序中的存在形式就是地址，說的再粗暴點，就是4或8字節的二進制數……
也就是說，在已經編譯完成的C++程序的眼裡，類的元數據已經變成二進制的地址碼了，如果某人在沒有源代碼的情況下想給這個項目寫一個反射機制，那麼他將不得不面對一大堆的：
0xb08dfe231a1c002e
0xb08dfe231bc128f6
0xb08dfe2417a90f5d
......看到這些，他長舒了一口氣，優雅地點燃了一根香煙，然後毫不猶豫地戳到電腦屏幕上：
鬼知道這是什麼玩意啊！！
如果原項目加個殼、模板元編一下再做個混淆加密的話那更沒法看了，因此如果一定要實現反射機制，一般都是把反射機制直接囊括到項目開發過程當中（就像上面那位大佬的文章中提到的那樣，原項目的作者也是反射機制的構造者）。
這樣的話就會存在一個上上上個世紀汽車行業出現的問題：
這輛車的件無法用到另外一輛車上！
這個反射機制無法用到別的項目上！
當然，這樣說可能有些絕對，但以C++的方式實現一個能夠廣泛用於所有項目的反射機制應該是極端困難的。
上面大佬的文章當中，這個C++的項目要使用反射機制，是藉助工廠模式實現的，關於這些的實現方法，詳見大佬文章（當然我自己也沒完全看懂）
那託管語言又如何呢
C#、Java，這兩種語言都是託管代碼的（C#使用.NET進行託管，Java則交給了JVM虛擬機）。
與C++不同的是，他們並不直接接觸系統底層，而是通過中間代碼訪問底層的。
中間代碼由誰處理呢，C#是通過.NET提供的CLR，產生的中間語言是程序集，而Java靠的是JVM，其中間產物是class文件。
如果有幸使用一些IDE打開這兩個文件往裡窺探一遭的話，我們應當不難從中找到這些元數據的信息。
這就好像，一群孩子進了幼兒園，一個託管老師全程進行看護。
把拔碼麻區上辦，我區悠貳園吶
當然，託管老師肯定是知道孩子叫什麼名的，訪問他們自然也是很容易的。同理，託管環境（或虛擬環境）也是一樣的，因為銜接上下兩層，因此把底層的元數據和上層的可讀文本構造反射的橋樑是很容易辦到的，因此，C#和Java都提供了一套非常完善的反射庫，他們可以被用於使用這兩種語言寫的任意一個類當中。
好了，道理我都懂，但為什麼要反射呢？
反射能幹什麼呢
舉個最簡單的例子
我……我有一個夢想，我想要這樣一個函數，能夠返回Person類是否有我所說的方法，但是我不知道Person類里有什麼，比如我想問他有沒有
Eat()方法，它返回true，我問他有沒有Fly()方法，它能返回false
好了，換作是你，你會怎麼實現這樣一個函數呢？？
而反射機制恰恰做到了！
你提供給反射機制一個字符串形式的函數名，反射機制不僅可以得知這個函數是否存在，甚至能幫助你去執行這個函數（Invoke）。
什麼，你不好問它有沒有某個函數？？好啊，反射機制甚至可以告訴你這個類都有哪些屬性哪些函數，繼承自誰，可見性如何，是否抽象等等。
那反射在什麼時候比較好用呢
上面那個例子其實就是一個經典的用途。
或者，我們可以考慮另外一個場景。
你寫了某個函數接受了一個抽象為
Object的對象，你希望，如果Object的對象存在方法Grow則調用之，否則什麼也不做。
這個時候首先可以通過反射機制確定方法是否存在，但即便方法已經存在，我們是無法直接調用的，因為對象已經抽象為Object，而Object並不存在方法Grow，所以直接調用就洗洗睡了。
我們不能具象回來么？？
如果我們知道類在抽象之前是什麼類型的時候，那當然可以具象化回來。
但是抽象雖然發生於編譯時或運行時（動態創建的對象），但具象類型的獲知卻是在編譯之前的代碼源文件，而且還有些時候你根本無法知道原類型，那也沒辦法拆箱。
注
這裏面我為了方便，也是想不出啥更好的詞
這裏我稱派生類向基類的多態轉化為抽象
反過來的過程稱為具象
那我還怎麼調用Grow呢
反射機制可以獲取到完整的可用方法的列表，我們在列表中找到了Grow，存在形式為Method/MethodInfo對象或乾脆就是個字符串。
但無論是哪種，obj.Grow();是不可能了，好在反射機制連這件事都考慮在內了——Invoke調用！！
反射機制不僅知道你想要什麼方法，還可以幫助你調用這個方法，這個調用就通過一個叫做Invoke的方法完成。
不同語言對Invoke的定義不盡相同但功能上大同小異，通過Invoke調用某方法的過程實質上是轉調和回調（或者是間接調用）。
間接調用比直接調用更加的強大靈活，但繞了遠路。
還有什麼比較宏大一點的應用么？？
宏大一點……好吧，其實每一個磅礴的工程都是從一點一滴做起的。
一個很經典的案例，就是上文那篇大佬文章里的一個常用功能——序列化（Serialization）
雖然C#和Java本身就有可以用於序列化的一些結構和功能庫（Serializable接口之類的），但是有些時候我們對序列化機制如果有更高的可定製性要求的時候，我們往往傾向於自己構建一套心儀的序列化功能庫。
於是乎就有一個最簡單的問題擺在面前：
現在有
Class1類的對象，還有Class2類的對象，還有Class3類的一些對象想要轉化成可解析的內容，以供發送或保存（當然這也就意味着，這些對象的所有屬性和狀態都要保存），但是這老大老二老三一家一個樣，屬性也各不相同，我又不想挨個單獨寫，那該怎麼辦呢？？
現在有了反射機制，問題就很容易解決了。三胞胎嫌分起來麻煩？？反射機制可以把他們安排的明明白白！！你可以向反射類提供一個完整的類名，反射機制就能保證給你這個類對應的可用屬性的列表，以及一整套處理方案（Get和Set），之後還不是想來啥來啥，美滋滋~~
當然，以上都是反射機制用途中小的不能再小的冰山一角，比如我還可以通過反射機制根據我的輸入創建我想要的類型的對象等等。
哇，反射這麼強大？？我要滿地反射！！
冷靜點！任何事物都有多面性，反射也不例外，我們看看反射機制有什麼特點，它到底是否適合所有情形。
極致靈動（Flexi Frenzy） 稀有屬性
反射機制可以讓你的代碼非常靈活，以不變應萬變。
這也正是反射機制帶來的最大的好處。
未卜先知（Fortune Tell） 普通屬性
反射機制是在運行時起作用，當然，運行期間發生什麼，編譯之前是無法獲知的，反射就是處理這件事的。
效率捉急（Emaciated Efficiency） 糟糕屬性
反射機制最大的問題！
反射機制的效率是十分低下的，首先在運行時獲取元數據再轉化成可讀形式就不是一個很快的過程，而反射的Invoke調用是個不折不扣的間接調用。
不當地使用大量反射會導致程序效率的急劇下降。
代碼膨脹（Code Expansion）
顯然，用反射進行調用的代碼往往比直接調用寫起來複雜，所以除非你寫代碼是按行數計工資，否則能直接調用就不要反射。
健壯風險（Robustness Risk）
反射機制一般允許用戶傳入字符串……
然後就是萬劫不復深淵之伊始
這時候用戶傳的字符串就可以非常的五花八門了，就好像一個動物園裡，反射機制是一個可愛的小動物，而遊客開始不分青紅皂白地對它投各種食，良莠不齊，可是你的反射機制很脆弱，它可禁不起這折騰，吃到不好的東西就會生病罷工（拋異常，然後中止），因此你這當奶媽奶爸就要多操心，幫它收拾（捕獲），告訴他如何分辨食物（預先判斷）……
不過呢，有些時候引入反射機制恰恰就是出於健壯性的考慮……
如果我養的不是個反射機制而是一隻熊貓的話我會上天的！！
總結
反射是個強大的武器，但使用應多加謹慎！
以上
【精選推薦文章】
智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選
想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計
廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益