VB.NET之旅（七）—軟弱的基類。本站提示廣大學習愛好者：（VB.NET之旅（七）—軟弱的基類）文章只能為提供參考，不一定能成為您想要的結果。以下是VB.NET之旅（七）—軟弱的基類正文
“既然說是軟弱，當然是指它象蛋殼一樣摧枯拉朽喽。這個問題其實很 好了解。順序總是由人來設計與編寫的，所以任務開端時思索不到某些問題當然 也是很正常的事。所以能夠在任務停止了一段時間後發現基類需求變卦。你想， 假如我在基類中更改了成員的數據類型，以及那些允許重寫的那些辦法和屬性， 那派生類及其子類還能正常任務嗎？尤其是當一個團隊中的多個開發人員一同來 創作基類和派生類時，就更是要命了。很多狀況下，大家能夠曾經把基類和一些 派生類編譯成二進制方式停止提交了。更改基類，重新編譯再散布，會牽一發而 動全身，招致項目的解體。所以我們把這叫做‘軟弱的基類’。也就 是說，它是整個工程中最單薄最致命的環節。”大李眉頭不斷緊鎖著，想必 是回想起了自己受打擊的閱歷。
“這麼嚴重呀，如今的軟件工程設 計辦法會不會對這個有很好的處理方案？”我努力想緩解一下大李的嚴肅神 情。
“假如對項目的後期設計思索盡能夠周詳，在工程施行中對項目的代碼 控制與相關性剖析做得踏實，會起到很好的效果。但是不論一團體如何努力，有 時還是無法防止對基類停止不可預見的更改。我們探索過很久，有了一些處置的 手腕。”
“真是成事在人呀，我們如今有什麼處理之道？ ”我也一下子振奮起來了。
“呵呵，並不是什麼完滿處理方案 。只能在某種水平上加重危害。我們常用的一個辦法，最直接的思想就是，把有 能夠發作的更改全都放在派生類中停止，不在基類中做。”
“ 這詳細是什麼意思呀，我還是不太明白。”我不好意思地撓撓頭。
大李淺笑著點搖頭，看來是知道我不會明白的了。“我們在基類中運用的是 籠統類，它內含的辦法與屬性只要定義，沒有停止完成，而把完成局部都放在派 生類中做。這樣一來，籠統類本身是無法被實例化的。但是它的益處顯而易見， 就是有能夠發作的完成上的更改都會只觸及到它的派生類了。VB.NET中就提供了 這樣的手腕。”
說著，大李就翻開VS.NET集成編譯環境，隨手寫了 一小段代碼：
Public MustInherit Class CBaseHenry Public MustOverride Sub subX(ByVal x As Integer) Public MustOverride Function fcnY(ByVal y As Integer) As Long End Class Public Class CDerivedHenry Inherits CBaseHenry Public Overrides Sub subX(ByVal x As Integer) '寫入完成的代碼 End Sub Public Overrides Function fcnY(ByVal y As Integer) As Long '寫入完成的代碼 End Function End Class
“這裡要留意兩個問題，一個是關鍵字，我們用 MustInherit來修飾類名，使類成為籠統類，在它的成員中，把辦法和屬性前參加 MustOverride修飾符表示它們必需在派生類中加以完成。第二個要留意的是，派 生類必需對一切用MustOverride標識的基類辦法和屬性都停止完成，只重寫了 subX，不寫fcnY編譯器會報錯的。”
“這確實可以處理一局部 問題，但好象只能處理在基類中停止完成的代碼有更改的問題，關於數據類型的 更改好象沒有什麼效果。”我看了好一會，收回了這樣的疑問。
“所以我方才說，是在某種水平上停止處理嘛。”大李也不由 笑了起來，“不過你提的這個問題，倒不是太費事，我們可以在派生類中用 Shadows來處理呀！（詳見本報上一期《重載與隱藏》）”
這倒是個 不錯的主見，我心中暗暗評價了一番。忽然我又想到一個問題：“假如基類 要做功用擴展，怎樣辦呀？”
“假如是要做擴展，最平安的方 法是添加新成員，而不是對基類的大肆修正。普通是往派生類添加設計時缺失的 新成員。最好不要運用Overloads關鍵字來命名與基類相反的成員，那樣往往會帶 給你意想不到的問題。最好重新定義新成員，命名上也要盡量與基類已有的成員 名區分開來。其實，也可以往籠統類基類中添加新成員的定義，但這樣一來，需 要為基類制定版本，雖然不會對使用順序形成消滅性的危害，但是應該要可以完 全地控制與管理自己的代碼。我們普通是不希望擴展基類的。”
我 曾經粗心上體會了大李的一片苦心：“您的意思，是不是指基類的軟弱問題 實踐上是客觀存在的，我們所做的就是要最大水平的減小這個問題帶來的危害？ ”
大李眼中閃過一絲贊許的笑意，颌首道：“沒錯，關於一個 使用順序的設計者來講，想運用面向對象辦法來開發，必需要在設計的時分精心 籌劃類的層次構造。普通來說，是有這樣幾個原則需求掌握的：
第一，遵 循先通用，再公用的准繩。先設計好層次構造中每一級別的類中的通用局部，也 就是提供應派生類承繼的成員和標識為Public的成員；
第二，在定義數據 類型和存儲區時要有預留量，以防止當前更改困難。例如，即便以後數據能夠僅 需求Integer類型就夠了，在設計時我們運用 Long 類型的變量。當然，最好能物 盡其用，也不要自覺縮小；
第三，在一個項目中，必需一致管理與分配團 隊中運用的一切的命名，以增加命名抵觸，這一點其實事關嚴重；
第四， 要運用提供可行的最低訪問權限的訪問修飾符聲明類成員。外部類成員應聲明為 Private；僅在類內與派生類才需求的成員應標志為Protected；Friend 數據成員 可以從類的內部訪問，但僅限於該模塊是定義該類的項目的一個組成局部；運用 Public標識的成員，只能是實例化時真正需求的內容，而且常常用在類層次構造 的底部。”
“也就是說，一個標准的操作，規范的命名體系可 以決議基類的健壯與否？”我不由感受了一聲。
“不對，應該 這樣說，可以決議的是給軟弱的基類穿上多厚的防護衣。由於基類一直都是軟弱 的。”大李更邪道。
我連聲贊同：“對，對。我如今是真正明 白為什麼總有人提編程標准的事情，我不斷以為是加強代碼的可讀性，沒想到， 對順序本身還有這麼大的協助。”
“當然，其實你仔細想一下 ，Overrides關鍵字的作用，不論要不要注明，編譯器都可以很方便地判別辦法或 屬性能否在基類中，簽名能否婚配，但是VB.NET要求我們必需標注，就是強迫開 發人員注明重載基類辦法或屬性的意圖，使開發進程更合理與無效。此外，還有 更重要的就是，我們要在工程理論中不時地學習與磨練，理解更多的知識，取得 更多的經歷，這樣才會生長為一名合格的順序設計師。就拿承繼來說吧，在.NET 中其實支持三種承繼方式：完成承繼、接口承繼、可視承繼。我們其實只用了第 一種承繼方式，你看，要學的東西是不是很多？”大李敵對地拍了拍我的肩 膀。
