本節內容：
1、剖析Hello,World程式
1.1初始類(class)與名稱空間(namespace)
2、類別庫的參考
2.1DLL的參考(黑盒參考)
2.2專案參考(白盒參考)
2.3建立自己的類別庫專案
3、依賴關系
4、排除錯誤
1、剖析Hello,World程式
1.1、類(class)構成程式的主體
1.2、名稱空間(namespace)以樹型結構組織類(和其他型別)
例如Button和Path類
命名空間可以有效的避免同名的類有沖突，
C#是完全面向物件的語言，整個程式都包含在一個類里面：class Program{}
當有引入命名空間：Using....相當于告訴程式如果我要寫一個類的時候，如果我沒有把這個類的命名空間在類名前標出來，就去我參考的命名空間里面檢索一遍，看哪個命名空間里面有這個類，就用這個命名空間里面的類就可以了，
比如：Console類有兩種參考方式：
第一種：不引入命名空間：System.Console.WriteLine();
如果還要用System里面的類每一次都要向上面一樣在類前加前綴(這叫權限命名)，顯得冗余，
那可不可以我寫Console編譯器就知道它是從System里來的呢？
第二種：引入命名空間：
Using System；
Console.WriteLine();以后參考System命名空間里面的類就不用加前綴了，這就是參考命名空間的方便之處，
*小技巧：找到某個類的命名空間，兩種方法
第一種：是通過檔案來知道，打開匯入的本地幫助檔案，搜索該類，
第二種：相對簡單的方法:把滑鼠放在這個類上面左下角會出現一個藍色智能標記，有兩個選項：Using System和System.Console分別表示參考命名空間的兩種方法，（編譯器比較聰明猜到了這個類屬于哪個命名空間）
注意不能圖方便把全部的命名空間都參考進來，會發生沖突，因為命名空間以樹型結構來組織類的，
不同的樹型結構也有可能有相同的類存在，這時若使用引入命名空間的方法來參考相關類就容易造成混亂；比如
Path類既屬于System.IO命名空間也屬于System命名空間，則這時就不知道參考哪個命名空間里面的Path類了，
這時應該采用第一種不引入命名空間的方法才能準確的參考不同命名空間相同名字的類，
如：System.Path或者System.IO.Path就可以清楚地區分不同命名空間里面名字相同的類了，
*再比如Button類有十多種，這時就凸顯出了命名空間的重要性，如果沒有命名空間就只能有一個Button類了,有效的解決類名的沖突，
*這樣也給我們一個設計思路，當我們在設計類的時候要給類一個精確地名字同時要非常精確的把它放在它應該在的命名空間里面，這樣既方便自己寫程式，也方便別人用我們程式的時候也能快速和舒服的找到我們的類，比如：自己創建了一個.h檔案，在別處參考時不僅要引入頭檔案.h還要引入這個自定義類的命名空間，讓他獨一無二，
2、類別庫的使用
就好比書，雖然知道這本書是哪個圖書館的，如果連圖書館都沒有用可能把書拿出來嗎？
所以有：類和命名空間是放在叫做類別庫的地方，類別庫就是類和名稱空間的物理基礎
(不同的技術型別的專案會默認參考不同的類別庫)
2.1、DLL(類別庫)（Dynamic link library）元件，的參考（黑盒參考，無源代碼）*NuGet簡介.
如果要使用相應的命名空間和類就要先參考相應的類別庫，在那里找類別庫呢？解決方案->參考,里面的都是你新建里不同型別程式程式默認參考的類別庫，雙擊其中一個類別庫，會彈出”物件瀏覽器”視窗，其中一層層列出了類別庫->各類別庫所包含的名稱空間->相關名稱空間包含的類，
*強調一點：不同的專案模板本質上建了專案之后相應地參考了不同技術（比如winform和WPF）所需要的類別庫，
如果我們除了模板參考的類別庫之外還想要參考其他類別庫怎么辦呢？日常作業中對類別庫的參考就兩種方式：
第一種：是對編譯好的DLL直接參考，這種參考我們叫黑盒參考，因為我們沒有DLL的源代碼；
第二種：我們有類別庫的源代碼，然后我們對源代碼進行參考，源代碼是放在專案里面，這叫做專案參考，或者叫白盒參考，能夠看到源代碼的，
兩種參考各有特點，需要注意的是當把DLL拿來之后一定要配一個說明檔案，不然用處不大，因為黑盒參考不知道源代碼就不清楚該DLL有什么名稱空間和類就無法使用，在那里添加類別庫？在解決方案->參考->右鍵->添加參考->右下角”瀏覽”添加本地DLL，這樣就把下載來的類別庫參考程式了，然后就可以對著說明檔案使用類別庫，（同樣可以使用上述方法查看這個類別庫有多少個命名空間和相關的類）
*黑盒參考存在的問題，若代碼存在錯誤，無法修改，還能告訴制作類別庫的人讓他改了，再編譯出DLL再發給我才行，另一方面，我的程式對這個引入的類別庫有了依賴性，即它的類別庫有問題我的程式也會有問題，這就是依賴，而在類的級別也會有依賴性，即我的類：如C#程式體都包含在 class Program中，呼叫了該類別庫的類，這兩個類之間也有依賴關系，連為一體，一方出錯，雙方都錯，*寫程式時一定要小心這個依賴關系，這個依賴關系大概有5,6種有的依賴關系很強，有的依賴關系很弱，我們盡量使用比較弱的依賴關系，這樣的話，我的程式就不至于出現某個底層的類出現問題我的上層所有的程式都不能作業，
解決辦法之一，弱的依賴關系：比如可以暫時先用一個相似的類替換該出錯的DLL，再繼續修成程式，等該DLL修改好再繼續使用該類別庫，怎么安排?這是比較高級的內容，
可以發現DLL的檔案就是MSDN檔案的縮影：MSDN里面有非常龐大的類別庫的檔案，在里面可以查找每一個類的資訊，包括方法、屬性、事件等，
想法：本來控制臺程式是不能顯示視窗的，但是如果引入相關類，就變得可以顯示視窗了，解決方案->參考->右鍵添加參考->程式集選項卡里搜索System.Windows.Forms,添加該類別庫，則該類別庫就是我們程式的一部分了，可以自由參考，參考DLL類前，如上面所說的要先，寫命名空間，方式發生沖突：Using System.Windows.Forms;再參考Form類就沒問題了，
使用新潮技術(NuGet)來解決比較復雜的依賴關系問題，程式和類別庫有一定的依賴，底層的庫是參考不了上層的庫，因為上層的類別庫需要許多底層的類別庫支持才能運行，但凡缺少一個底層的類別庫沒有參考進來，上層的類別庫都不能使用，參考的時候硬碟里面再有重名的類別庫或者版本不同的這樣參考起來很可能在程式中引入一些非常難以排除的錯誤，因為這時候你只有DLL，沒有源代碼，幾乎可以說是“蒙著眼睛參考類別庫”這是很危險的！特別是對于大型的專案，
解決方法：以一個類別庫包的形式放在網上，客戶要用我敲一個命令一組類別庫都包含到專案里面去了，不用手動的添加參考類別庫，這樣就非常安全，高效，這就是NuGet技術：解決方案->參考->管理NuGet程式包，在這里面搜索相關類別庫集合而成的包，安裝它，就會在我們專案的參考里自動添加相關的類別庫，而且新添加的類別庫都是由NuGet管理不用擔心，版本啊，缺少某個類別庫之類的問題了，十分方便，*總結：用NuGet去參考網上一些非常好的類別庫，
2.2、專案參考（白盒參考，有源代碼）
自己寫類的時候有命名空間是為了讓別人參考更加方便，一個專案隸屬了多個solution（解決方案）這就專案的重用，當我們擁有別人類別庫的源代碼，可以在解決方案右擊->添加->已有項，這樣就可以把別人的專案檔案添加到我們的程式里了，此時在右擊參考->添加，在解決方案選項卡就可以看到我們添加的別人專案里的類別庫了，選擇添加即可開始參考該專案的類別庫，可見同一個解決方案下的不同專案要通過上面的方法才可以使用彼此的類別庫，
Debug修的，排錯的找的是Root cause！不要在補丁上打補丁，不在問題根源修復只會越弄越差，
這就是白盒參考，
2.3、建立自己的類別庫專案
右擊解決方案->添加->新建專案->選擇類別庫(class library)專案，class library它不是可執行的檔案，它編譯出來的結果就是DLL（類別庫），在生成的CS檔案里面進行類別庫相關類與方法的撰寫，在創建的類別庫專案上右擊->生成就會在該專案本地原始碼檔案夾bin->debug檔案夾里面生成DLL（類別庫檔案）這樣附上使用說明就可以傳播出去了，
3、依賴關系
類和類之間是有依賴關系的，類別庫和類別庫之間也是由依賴關系的，那么如果底層的類或者類別庫有問題，那么上層的類或者類別庫作業也會不正常，所以依賴關系（也叫耦合關系）是非常重要的，
3.1、類（或物件）之間的耦合關系
3.2、優秀的程式追求”高內聚，低耦合”（教學程式往往會違背這個原則）
高內聚：指一些資料一些功能該屬于哪些類就放到哪些類里面去，要精確的放在這些類里面去，這就叫高內聚；
低耦合：類與類之間的關系盡可能的低，盡可能的松，就叫低耦合，
類別庫的設計也是這個原則，一些類該放到哪些類別庫里面就放到哪些類別庫里面，不要亂放，類別庫與類別庫之間的關系也盡量是低耦合的，低依賴的，這樣程式結構才會非常清晰，
3.3、UML（通用建模語言）類圖：
展現類與類之間的關系，
4、排除錯誤
4.1、仔細閱讀編譯器的報錯，
4.2、MSDN檔案與搜索引擎結合，
當你看到一大片錯誤的時候不見得真的有這么多錯誤，有的時候就是一個很小的錯誤就造成這么多錯誤，比如：中文的標點符號，（實際上編譯器是有一定智能的如果陳述句正確，會高亮顯示）；真正難排除的錯誤是編譯器認為是對的，但是運行會出錯這就是邏輯錯誤，需要一步步debug來解決，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/115458.html
標籤：C#
上一篇：正則運算式的基本語法