C# Reflection 一些雜項記錄(書中介紹之外的)

最近的程式設計中，用到滿多Reflection(反映)的做法。
以下我先簡單記錄這陣子的心得，首先先做一個範例說明:
MyLibrary-> Class library project.
WindowsFormsApplication2->Windows form project.

 

MyLibrary.dll程式碼如下:(建立一個book class)


1.取得對應的Type
一般我們取得的方式都是使用Assembly.GetTypes() 或是 Assembly.GetType()，
這些方式都是滿常用的，今天要介紹的是比較不同的。
其實在Type類別中有一個static GetType(string)，這個也可以取得相對應的Type。
 
執行結果：


2.取得實體物件
在這裡一般書上都會先找出ConstructorInfo這個建構式後在去取得實體物件，如下說明:
 
執行結果：
 

今天要記錄的是滿少看到的用法(對我啦! XD)，Activator.CreateInstance

執行結果：

 

3.動態加入事件
這裡是使用EventInfo Class


執行結果：



先簡單記錄到這，以後要補充的再加上！！

Chain Constructors

在Refactoring to Patterns一書中有提到Chain Constructors的觀念，
書中的意思是說，在不同的建構式中，出現重複的程式碼，
可以借由Chain Constructors來將複雜的程式碼簡化

譬如今天建立一個物件，其建構式如下

在MyEmployee的建構式中，提供了三個不同的建構式，
因為對這個MyEmployee的物件中，Telephone與Fax是可有可無的條件，
所以希望是說藉由不同的建構式，來建立適當的物件即可，

但~注意到了嗎?以上的程式碼是不是看得很礙眼?
重複的程式碼不斷的出現在建構式中，其實!!!
我們可以精簡如下:


看~是不是簡單多了??
在最終的建構式中，提供全部的條件需求，
其他的兩個建構式分別去呼叫最終的那個建構式，
這樣不僅是在維護上更加方便，在觀看程式碼的時候也會比較清晰。
簡單記錄下來，提供日後參考。

WinForm 重構

這次因為新的功能需求，需要改寫之前所撰寫的程式功能，
Business Logic幾乎都沒變動，唯一變動的是UI畫面，
以及前端登入時的一些資料驗證功能，但這些小變更卻花了我不少時間重構。
為什麼呢?請聽我慢慢細說。。。

當初在設計這支程式的時候，是有遵循MVC的設計方式，
該是UI該做的顯示畫面，或是Model該處理的Business Logic都是有相當程度的區隔
但是卻沒有相當嚴謹的遵循，導致有些Logic還是放在UI層，
例如:Form Class裡頭竟然還有Business Logic，當我在重新修改功能的同時，
也順便將這些不該存在的東西全部抽離。

UI層就完全是在顯示資料用，他不需要管底層到底做了哪些事情，
而Model則是完全處理關於Business Logic，這樣把權責給區分出來，
這樣重構下來對以後在維護的時候會更加方便。

另外，再提到一個小觀念，其實這是之前就已經知道的事情，
但是卻還是到現在才又開始想起，我先提一段程式碼。如下所示:

 
其中tbxName、tbxage是Textbox控制項，一般在寫WinForm的時候，
我在想大部分的人都應該跟我一樣，都很偷懶直接在Button的事件中寫完所有的事情，
不管是方便性來說，或是以後在維護來講其實都挺方便的(只要看這個Method就好)

但是。。。
今天若又有一個Button要提示未滿18或已滿18，
不知道你是不是也會跟我一樣這樣寫?

 



這樣真的可以Work，但是各位看官，您發現了嗎?
程式裡多了好幾句反覆的程式碼，這樣的寫法很不恰當，
因為萬一又多了一個Button又要做其他功能，是不是又要再寫一次轉換int的程式?
(這裡還不包括是不是會遇到不是int的錯誤)

這裡比較好的作法應該是這樣，設計成屬性
(當然若是只在這個Class中使用請將層級換成private)
這樣的好處是，程式可以重複使用，另外也可以加入驗證機制。
 

另外寫在Button的程式碼，是不是又更簡單易懂??


這麼簡單的東西，我竟然現在才想到，真的是。。。
記錄下來以後可以這樣設計!!