Anytao你必須知道的.NET

簡體傳統

[你必須知道的.NET] 第四回：后來居上：class和struct

提起class和struct，我們首先的感覺是語法幾乎相同，待遇卻翻天復地。歷史將接力棒由面向過程編程傳到面向對象編程，class和struct也背負著各自的命運前行。在我認為，struct英雄遲暮，class天下獨行，最本質的區別是class是引用類型，而struct是值類型，它們在內存中的分配情況有所區別。由此產生的一系列差異性，本文將做以全面討論。

我們可以簡單的理解，class是一個可以動的機器，有行為，有多態，有繼承；而struct就是個零件箱，組合了不同結構的零件。

[你必須知道的.NET]第九回：品味類型---值類型與引用類型（中）－規則無邊

從內存角度來討論值類型和引用類型是有理有據的，而從規則的角度來了解值類型和引用類型是無邊無際的。本文旨在從上文呼應的角度，來把這個主題徹底的融會貫通，無邊無跡的應用，還是來自反復無常的實踐，因此對應用我只能說以一個角度來闡釋觀點，但是肯定不可能力求全局。

現在，我們從幾個角度延伸了上回對值類型和引用類型的分析，正如本文開頭所言，對類型的把握還有很多可以挖掘的要點，但是以偏求全的辦法我認為還是可取的，尤其是在技術探求的過程中，力求面面俱到的做法并不是好事。以上的幾個角度，我認為是對值類型和引用類型把握的必經之路，否則在實際的系統開發中常常會在細小的地方栽跟頭，摸不著頭腦。

品味類型，我們以應用為要點撬開值類型和引用類型的規矩與方圓。

品味類型，我們將以示例為導航，開動一個層面的深入分析，下回《第十回：品味類型---值類型與引用類型（下）－應用征途》我們再見。

[你必須知道的.NET]第十回：品味類型---值類型與引用類型（下）－應用征途

這些示例主要從從基礎的方向入手來剖析前前兩回中的探討，不求能夠全面而深邃，但求能夠一點而及面的展開，技術的魅力正在于千變萬化，技術追求者的力求卻是從變化中尋求不變，不然我們實質太累了，我想這就是好方法，本系列希望的就是提供一個入口，打開一個方法。示例的詳細分析可以下載[類型示例代碼]，簡單的分析希望能帶來絲絲愜意。

值類型和引用類型，要說的，要做的，還有很多。此篇只是一個階段，更多的深入和探討我相信還在繼續，同時廣泛的關注技術力量的成長，是每個人應該進取的空間和道路。

品味類型，為應用之路開辟技術基礎。

品味類型，繼續探討還會更多精彩。

[你必須知道的.NET]第十一回：參數之惑---傳遞的藝術

簡單的來說，參數實現了不同方法間的數據傳遞，也就是信息交換。Thinking in Java的作者有過一句名言：一切皆為對象。在.NET語言中也是如此，一切數據都最終抽象于類中封裝，因此參數一般用于方法間的數據傳遞。例如典型的Main入口函數就有一個string數組參數，args是函數命令行參數。通常參數按照調用方式可以分為：形參和實參。形參就是被調用方法的參數，而實參就是調用方法的參數。

接下來，我們接上面的示例討論，重點將參數傳遞的基礎做以交代，以便對參數之惑有一個從簡入繁的演化過程。

完成了對值類型與引用類型的論述，在這些知識積累的基礎上，本文期望通過深入的論述來進一步的分享參數傳遞的藝術，解開層層疑惑的面紗。從探討問題的角度來說，參數傳遞的種種誤區其實根植與對值類型和引用類型的本質理解上，因此完成了對類型問題的探討再進入參數傳遞的迷宮，我們才會更加游刃有余。我想，這種探討問題的方式，也正是我們追逐問題的方式，深入進入.NET的高級殿堂是繞不開這一選擇的。

[你必須知道的.NET]第十三回：從Hello, world開始認識IL

1988年Brian W. Kernighan和Dennis M. Ritchie合著了軟件史上的經典巨著《The C programming Language》，我推薦所有的程序人都有機會重溫這本歷史上的經典之作。從那時起，Hello, world示例就作為了幾乎所有實踐型程序設計書籍的開篇代碼，一直延續至今，除了表達對巨人與歷史的尊重，本文也以Hello, world示例作為我們扣開IL語言的起點，開始我們循序漸進的IL認識之旅。

[你必須知道的.NET] 第三回：歷史糾葛：特性和屬性

通過對概念的澄清和歷史的回溯，我們知道特性和屬性只是在名稱上有過糾葛，在MSDN上關于attribute的中文解釋甚至還是屬性，但是我同意更通常的稱呼：特性。在功能上和應用上，二者其實沒有太多模糊的概念交叉，因此也沒有必要來比較其應用的異同點。本文則以特性的概念為重點，來討論其應用的場合和規則。

我理解的定制特性，就是為目標元素，可以是數據集、模塊、類、屬性、方法、甚至函數參數等加入附加信息，類似于注釋，但是可以在運行期以反射的方式獲得。定制特性主要應用在序列化、編譯器指令、設計模式等方面。

DllImport特性，可以讓我們調用非托管代碼，所以我們可以使用DllImport特性引入對Win32 API函數的調用，對于習慣了非托管代碼的程序員來說，這一特性無疑是救命的稻草。

Attribute的最大價值在于:通過分析一些附加信息來決定執行某一個邏輯分支

-------出自框架設計Via C#

[Anytao.NET] 必須知道的設計模式

設計模式是面向對象思想的集大成，GOF在其經典著作中總結了23種設計模式，又可分為：創建型、結構型和行為型3個大類。對于軟件設計者來說，一般的過程就是在熟練掌握語言背景的基礎上，了解類庫的大致框架和常用的函數和接口等，然后多再在百般錘煉中，提高對軟件設計思想的認識。

軟件設計者要清楚自己的定位和方向，一味的沉溺于技術細節的思路是制約個人技術走向成熟的毒藥。因此，學習軟件設計，了解軟件工程，是每個開發人員必備的一課。筆者在此不想詳細的描述各個設計模式的細節，我想google和baidu上的資料已經多如牛毛了。而且，爭取的學習方法也不是了解所有的設計模式就可以無敵于天下。我所強調的學習方法就是在熟練掌握基本要素的基礎上，了解大致的框架。這一條不僅是學習類庫的方法，對設計模式來說是可行的。同時，切記的是在平時的積累中，不斷的體會和實踐。

策略模式，將易于變化的部分封裝為接口，通常Strategy 封裝一些運算法則，使之能互換。Bruce Zhang在他的博客中提到策略模式其實是一種“面向接口”的編程方法，真是恰如其分。

適配器模式，在原類型不做任何改變的情況下，擴展了新的接口，靈活且多樣的適配一切舊俗。這種打破舊框框，適配新格局的思想，是面向對象的精髓。以繼承方式實現的類的Adapter模式和以聚合方式實現的對象的Adapter模式，各有千秋，各取所長。看來，把它叫做包裝器一點也不為過，

不要拿著GOF的書，從頭看到尾，對我來說那是圣經也是字典；在軟件設計中體會設計模式，設計就是不斷的由需求生成的重構；結合.NET Framework框架來學習設計模式在.NET中的應用，對我們這樣的菜鳥來說是一舉兩得的事，即體味了設計，又深諳了框架；把體會拿來共享。

2007：遠見、勁取、專注

2007，你好。

2007，從此開始了。我相信自己已經準備好了一切來走得更好。告別美好的2006，那是起伏跌宕的一年，也是激情收貨的歲月。2007，我將從新開始，在新的人生道路上開啟勇往直前的未來。

2007，技術升級是我的核心競爭。在.NET的世界里，我要做好以下幾個目標：C#、Xml、WebServices技術，熟練使用VS2005/SqlServer2005。對人生的目標還有更大更多，這些我將放在最顯眼的思想角落，每天重復的告訴自己的位置和方向。相信，那將是美好的路，我當然會走好。

2007，祝愿博客園的朋友們新年快樂。同時，祝福自己和家人平安健康快樂。

在2007，我將心懷遠見，進取每天，專注技術，思考人生。

[轉]談談技術原則，技術學習方法，代碼閱讀及其它

在工作上以實用為主導，哪個實用學哪個，要以最小的努力獲取最大的成效。

工作，就要堅持這樣的原則。要能夠分辨出價值，找能夠提高價值的去做。即使這樣違背一般規律，違背技術教條。

學習上以簡單，核心的東東為主。可學可不學的不要學。復雜的東西除非你想要成為這方面的專家，就不要學。

（1）一錘子買賣：直接new就行了

（2）你是我的唯一：單例

（3）千年等一回：對象池，原型，緩存

（4）似曾相識燕歸來：享元

（5）我看過GOF：工廠，抽象工廠

（6）不要問我從哪里來：IOC

歸納起來，大概偶覺得有用的方法就是這四種：

拜師學藝：以案例為主的學習，第一手資料最可靠。多看源碼，多看現有方案。沒事多寫代碼。

左右互博：同樣的問題，多學習多研究幾種解決方案。只學習一種容易障目，不通過比較，不能清楚某種軟件，某種解決方案，某種設計模式的優缺點。在時間可能的情況下，多試一試不同的解決方法。

庖丁解牛：拿到東西就橫豎兩刀，分成橫向的肋骨和縱向的脊椎，剩下的都是皮肉。對于絕大多數OO軟件都實用。不實用不是你的問題，是軟件寫的有問題。對于自己寫的軟件，沒事也可以試一試劈一下，軟件沒嘩啦嘩啦散開證明寫的有問題。

吸星大法：任何軟件都有歷史問題，任何方法都有歷史問題。軟件要兼容呀，公司要宣傳呀，所以很多東東不是它表面的那樣。.net對底層綁定的那么厲害，這些都是歷史遺留問題。所以，學習一個東東，最好向前翻幾個版本，看看在該軟件演化過程中發生了哪些故事，這些故事的背景是什么，每個故事都意味著一些trade-off，從中間可以學習很多軟件設計知識，這樣學習，相當于把別人的實戰經驗據為己有，多爽啊。這樣做的另一個意義是可以培養自己對技術的預測能力，比別人多看一步就是一個很大的優勢。

閱讀代碼如果順序不對,第一頭就扎進這些細節,那就完了.對主要流程的掌握和對層次的掌握是第一位的.對設計模式的了解還是其次. ---A good way to learn and use.

[轉載]一個發生在亞洲服務器上的真實故事!

轉載自：http://club.yule.sohu.com/r-joke-1511712-0-5-0.html

之所以在園子里轉載非技術的東西，只是因為它讓我承受了無限的感動和動力，有空翻出來看看，依然心潮澎湃。

轉載正文：

我在新網游魔劍的國際服務器里看到過這一幕：

當時中國人修建的一個城市被韓國人攻打。由于中國人的級別很低，最高的只有40級，（而韓國人的部隊基本全在60級以上）所以中國人幾乎被全滅。這時候守城的將軍被迫向整個魔劍世界發起求援。這時候一個驚人的事情發生了。從魔劍的各個角落趕來了一批批的隊伍。他們前赴后繼，如同潮水一樣沖向中國城，而他們無論名字是什么，來自哪個城市，他們所有的人身后的后綴都是一個.CN ！

韓國人被擊退了，他們怎么也不相信這個事實。100個韓國人倒在中國城的門口。他們殺死了至少2000個以上的中國人及其援軍。但是他們還是失敗了。因為還有不計其數身上帶著.CN的玩家向中國城進發，最遠的要走上1個小時的路程（在魔劍里，被殺死后只能從本城復活，而且地圖很大，有的城市的間隔能讓你走上2小時）。

勝利后，中國城的將軍感謝這些不認識的援軍。忽然發現，這些.CN不全是中國玩家。他們當中有很多是新加坡人，馬來西亞人，印尼人，美國人……但是他們都是中國的后裔，他們身上流著中國人的血。尤其，一個有組織的軍團（200人左右）一直在城側進行自殺式的沖擊，死傷慘重。最后只剩下9人幸存。當將軍問他們來自哪里的時候，他們說，我們是臺灣人。我們是從距離這里有1個半小時路程的日月城趕來的。這是我們能提供的所有精銳戰士了。你們有難，我們一定會來幫忙的，我們是兄弟……

那個將軍，那個年近30歲的大老爺們。在電腦前，看著這些來自世界各地的中國后裔，痛苦失聲…………

這就是中國人。世界上的中國人！

也許，你說的是事實，但是，我寧愿不信。

因為，我還記得那個臺灣人的話：你們有難，我一定會來幫忙的，我們是兄弟…………

發了這個帖子，沒是什么別的意思，只想告訴大家：中國是世界上所有中國人的中國。

不要被狹隘的地域阻擋我們的視線。

不是所有的海外華裔都那么爛。

我們是兄弟

我們都是炎黃的子孫！我們都有龍的血脈！不要因為一小撮敗類而損壞所有華人

[從架構到設計]第二回：對象的旅行---對象和人，兩個世界，一樣情懷

對象和人，兩個世界，一樣情懷

對象的載體是CLR，而人的載體是社會。CLR提供了對象賴以生存的規則，稱之為語法，例如類型、繼承、多態、垃圾回收等等，對象世界建立了真正的法制秩序；而社會提供了人行走江湖的秩序，稱之為法律，例如版權、人權、產權，這是我們力圖實現的社會秩序。

程序世界其實和人類世界有很多相似的地方，本文就以這種類比的方式來詮釋程序世界的主角如何類似于人類社會的主角，以演化推進的手段來描述面向對象程序世界的主角：對象由生而死的全過程，借以品味一下復雜的人類世界主角。人，也是可以簡單的。所以這是一種相互的較量，也是一種相互的借鑒。

鄙人不才，訪問級別部分的類比，始終找不到得心應手的類比來詮釋，希望大家給以建議。另外，關于本文的其它部分，若有不妥，望拍磚為上。

[活動.思考] 參加微軟創新日，技術的方向在哪里？

這就是簡短的一次參與，匆匆茫茫間，關于技術的感想油然而生。

微軟將Office作為新的開發平臺，整合到系統架構中，這就是Office Business Application，簡稱OBA，相信這種力度會越來越大。講師以實際的在線示例為例，講解了關于一個大型公司的零件查誤到維修的全過程，在講解中包括了眼花繚亂的技術熱點，主要包括：SharePoint 3.0、WPF/Siverlight、Visual Earth、Office Communication Server、InfoPath、Outlook/OWA等等，不盡而然。一個及其負責的業務系統，設計到數據庫、工作流和業務定制等多方面的問題，都迎刃而解，希望給大家以啟示。

參加微軟技術大會，每年都有好幾次，每年都有好多場，但是幾乎每次的技術都有所不同，微軟是一個技術創新型的公司，領導了全球的技術方向和技術眼球，日新月異，作為技術開發人員，我們好像追的太累了。就連微軟講師也坦言，還有人在用.NET1.1，現在都.NET3.5beta了，我看著講臺上一個一個粉墨登場的技術名字，不禁問了自己？

Where is your way?

想了想，給了自己答案和安慰：

Pick one, not all.

那么，大家的答案呢？肯定每個人都有自己的漢姆雷特，但是對技術我只能說，眼光和興趣很重要。

就分享這些吧，今年的TechEd可能會在11月召開，那又是一場更大的盛會，希望有時間去參與。

[從架構到設計]目錄導航

你會發現在日新月異，紛繁復雜的技術領域里，一切都在變，一切都在趕，我們拼命的狂追，換來一片的豪賭。唯一不變的，一是底層，二是設計。所以我只關注這兩個，也只關注這兩個，這是我認為的學習方法論中的第一守則：確定不變的追求方向。

提起面向對象，每個程序設計者總會說出一堆自己的理解，有獨特的、有偏廢的，不盡而然。但是無論所云，幾個基本的概念總會得到大家的首肯，它們是：類、對象、繼承、封裝和多態。很對，差不多就是這些概念構成了面向對象設計開發技術的基本邏輯，成為數以千萬計程序設計者不懈理解和實踐的標語。而實際上，理解面向對象一個重要的方法就是以實際的生活來類比對象世界，對象世界的邏輯和我們生活的邏輯形成對比的時候，我們的理解將會更有親切感，深入程度自然也就不同以往，因為誰能對生活沒有理解呢？

本文，就從對象這一最基本元素開始，進行一次深度的對象旅行，把.NET面向對象世界中的主角來次遍歷式曝光。把對象的世界和人類的世界進行一些深度類比，以人類的角度來戲說對象，同時也以對象的邏輯來反思人類。究竟這種品查，會有什么樣的洞悉，看我且來演義。

本篇純屬戲說，若有雷同，望請笑納。

[從架構到設計]第一回：設計，應該多一點

設計就像是轉魔方，你必須面面俱到。

anytao開始想嘗試嘗試寫點設計的東西了，只所以有了這個“突如其來”的想法，原因其實很簡單：因為對設計、架構、分層、模式，我很陌生。因為陌生，所以接觸，因為接觸，所以隨筆。系列之構思就這么誕生了。因此，這個系列是個方法論，是個雜文集，也是個見證史。我不期望能收獲多少掌聲，但求能保持更多交流。作為技術的狂熱追求者，我始終認為兩件事情是技術的立命之本：

底層、框架，因此有了[你必須知道的.NET]系列，以追求技術細節

設計、架構，因此有了[從架構到設計]系列，以追求技術宏觀

因為，你會發現在日新月異，紛繁復雜的技術領域里，一切都在變，一切都在趕，我們拼命的狂追，換來一片的豪賭。唯一不變的，一是底層，二是設計。所以我只關注這兩個，也只關注這兩個，這是我認為的學習方法論中的第一守則：確定不變的追求方向。

那么這個系列將關注些什么方向呢？

Architecture---架構

Method&Process---設計方法與設計過程

OO--面向對象

Design Pattern---設計模式

Learning Method---學習方法論

當年，petshop作為.NET和J2EE兩個派別之爭的產物，坐在了潮流的風口上，時間已然過去，當時硝煙早已消失。我們慶幸的是petshop一路走來，從1.0到4.0，綜觀其設計的脈搏，能夠感受到架構的日漸成熟和演變，這是技術之爭留給我們最大的看點。

沒有一成不變的設計，也沒有一成不變的架構。方案是永遠隨著需求，隨著技術而不斷重構，設計之美就體現在不斷的否定與自我否定中。