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，综观其设计的脉搏，能够感受到架构的日渐成熟和演变，这是技术之争留给我们最大的看点。

没有一成不变的设计，也没有一成不变的架构。方案是永远随着需求，随着技术而不断重构，设计之美就体现在不断的否定与自我否定中。