最近下载了并使用了Visual Studio 2010旗舰版，种种强大、方便之处，不一而足，此处不多谈。但有一个问题却困扰了许久——    在编程过程中发现Visual Studio 2010的代码编辑器总出现一些莫名其妙的问题。例如，输入Try然后按Tab生成语句块之后，光标点击代码编辑器之外任何位置（包括工具栏、菜单），都会在原光标位置处再插入一个Try，此现象并不固定，有时是原来输入的一个单词，有时是一个字母，甚至你编写了一会程序生成并进行调试，都会在光标处插入一些乱七八糟的字符，而且有时蹦出

Template Method模式是无处不在的，如果你只想掌握一种设计模式，那么它就是Template Method!缘起——变与不变变化——是软件设计的永恒主题，如何管理变化带来的复杂性？设计模式的艺术性和复杂度就在于如何分析并发现系统中的变化点和稳定点，并使用特定的设计方法来应对这种变化。动机（Motivation）在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各

由系统复杂度谈起假设我们要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为。其中坦克系统由引擎、控制器、车轮、车身等各子系统构成。public class Wheel{ public void WAction1(){...} public void WAction2(){...}}public class Engine{ public EAction1(){...} publi

抽象与实现根据依赖倒置原则，抽象不应该依赖于实现细节，实现细节应该依赖于抽象。抽象A依赖于抽象B，实现细节b也依赖于抽象B。这要求是抽象B比较稳定，实现细节b倾向于变化。问题是：如果抽象B由于固有的原因，本身并不稳定，也有可能变化，怎么办？举例：如果要开发一个同时支持PC和手机的坦克游戏，游戏在PC和手机上功能都一样，都有同样的类型，面临同样的功能需求变化，比如坦克可能有多种不同的型号

背景知识：耦合与变化耦合是软件不能抵御变化灾难的根本性原因，不仅实体对象与实体对象之间存在耦合关系，实体对象与行为操作之间也存在耦合关系。动机（Motivation）在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如需要对行为进行“记录、撤销/重做(Undo/Redo)、“事务”等处理。这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将

要解决的问题——面向对象的代价面向对象很好地解决了系统抽象性的问题，同时在大多数的情况下也不会损及系统的性能。但是，在某些特殊的应用中，由于对象的数量太大，采用面向对象会给系统带来难以承受的系统开销。比如图形应用中的图元等对象，字处理应用中的字符对象等。动机（Motivation）采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方

对象窗口的问题:在面向对象系统中,我们常会遇到一类具有"容器"特征的对象——即它们在充当对象的同时又是其他对象的容器。public class SingleBox:IBox{ public void Process(){...}}public class ContainerBox:IBox{ public void Process(){...} public ArrayList getBo

缘起——直接与间接人们对于复杂的软件系统常常有一种处理手法，即增加一层间接层，从而对系统获得一种更为灵活、满足特定需求的解决方案。动机（Motivation）在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者或者系统结构带来很多麻烦。如何在不失去透明操作对象的同时来管理、控制这些对象特有的复杂性？增

 缘起假如我们需要为游戏中开发一种坦克，除不同型号的坦克外，我们还希望在不同场合中为其增加以下一种或多种功能：比如红外线夜视功能，水陆两栖功能，卫星定位功能……等等。//抽象坦克public abstract class Tank{ public abstract Shot(); public abstract Run();}//各种型号public class T50:Tank{..

动机（Motivation）在软件构建的过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维护一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。意图（Intent）用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显

动机（Motivation）在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时让这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式。意图（Intent）提供一种方法顺序

背景：发布——订阅模型动机（Motivation）在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。意图（Intent）定义对象间的一

     最近应公司的需要开发一个GIS系统，由于以前使用MapInfo公司的MapX开发过程序，自信应该使用最新的MapXTreme和Visual Studio2008来进行开发没问题，很快从MapInfo官方网站下载了最新的试用版MapXtreme，准备开始开发，没想到首先这东西就给我来了个下马威，原来在MapX下用得好好的地图文件，就是无法加载到地图中。使用MapXtreme2008自带

创建型模式*Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。*Factory Method，Abstract Factory，Builder都需要一个额外的工厂类来负责实例化的“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。*如果遇到“易变类”，起初的设计通常从Facto

 背景：某些对象请求的接受者可能多种多样，变化无常……动机（Motivation）在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者。如果显式指定，必将带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时来决定处理请求，从而使两者解耦。意图（Intent）使多个对象都有机会处理请求，从而避免请求

背景：对象状态影响对象行为。对象拥有不同的状态，往往会行使不同的行为。动机（Motivation）在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化。例如文档处于只读状态时其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？意图（Intent）允许一个对象在其内部状态改变时改

背景：类层次结构的变化。类层次结构中可能经常由于引入新的操作而使类型变得脆弱。动机（Motivation）在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？意图（

背景：对象状态的回溯对象状态的变化无端，如何回溯/恢复对象在某个点的状态？动机（Motivation）在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其它对象得到对象的状态，便会暴露对象的细节实现。如何实现对象状态的良好保存与恢复同时又不破坏对象本身的封装性？意图（Intent）在不破坏封

背景：对象可能经常需要使用多种不同的算法，但是如果变化频繁，会将类型变得脆弱。这就是算法和对象的耦合。动机（Motivation）在软件构建过程中，某些对象使用的算法可能多种多样，经常改变。如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一种性能的负担。如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？意图（Int

动机（Motivation）在软件构建过程中，如果某一领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式将面临非常频繁的变化。在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。最常见的例子：正则表达式的使用。意图（Intent）给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使

适配，即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。简言之是“转换”。动机（Motivation）在软件系统中，由于应用环境的变化，常常需要将“一些现在的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？意图（Intent）将一个类的接口转换

Prototype原型（创建型模式）依赖关系倒置抽象不应该依赖于实现细节，实现细节应该依赖于抽象。抽象变化的速度比较慢，细节变化相对是更快一些。动机（Motivation）在软件系统中，经常面临着“某些结构复杂的对象”的创建工作，由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定的一致的接口。如何应对这种变化？如何向“客户程序”（使用这些对象的程序）隔离出这些“易

从耦合关系谈起耦合关系直接决定着软件面对变化时的行为。模块与模块之间的紧耦合使得软件面对变化时，相关的模块都要随之更改。模块与模块之间的松耦合使得软件面对变化时，一些模块更容易被替换或者更改，但其他模块保持不变。客户需求的变化应该是软件工程师需要解决的问题，而不应该是他们抱怨的话题。这需要谈到敏捷软件开发方面的问题了。软件界存在一个公理：抽象部分变化慢，具体部分变化快。或者说高层变化慢，低

讲师：徐长龙：vsts_china@hotmail.com泛型1）概述基于Object的解决方案，会有性能问题（如装箱和拆箱），而且不是类型安全的。如果要解决这种问题，可能要写特定类型的数据结构，这样一来造成代码冗余，重用率不高，一个数据结构的变更要将所有类型的数据结构做相应的修改。于是引入了泛型。2）什么是泛型？通过泛型可以定义类型安全类，而不会损害类型安全、性能或工作效率。

编码习惯1.命名规范，接口用I开头做前缀，异常类使用Exception作为后缀。内部成员变量用Camel命名法。小写开关，每单词首字母大写。2.使用有意义的变量名称和名称空间。有返回值的方法形如GetMyObjectState（）。3.所有的成员变量都应该声明在顶部，同时使用一个空行来将它们和属性、方法分开。4.总是将大括号放在一个新行上。委托再议定义委托实际上是定义一个“类型”的委托

Component-based Design and Programming基于组件编程有很多的优势：代码重用，团队支持，多语言开发和独立更新。在1990年，COM是微软流行的基于组件开发的模型。.NET替代了COM，提供了一个全新模型：语言独立的、注册自由、版本明确……建立组件什么是组件？组件＝＝编译后的实体。组件在.NET中就是Assembly（exe/dll）。组件与物理打包相关

对于大部分商业应用程序，核心的设计在于数据层和商务逻辑层。没有一个“正确”的解决方案，只能按需交替使用……多层设计概述表现层、商务逻辑层、数据访问层和数据存储。原因：分享逻辑思维的需要。团队或多语言开发的需要。重用商务逻辑与数据层的需要。这里的多层是逻辑设计，打包和旋转是物理设计。  商务逻辑层支持商务过程中所有涉及安全、商务规则（逻辑）和数据的处理（校验、数据操作）。

异常概述（Exception)异常是当程序发生错误时产生的一种信号。在.net中广泛使用。例如：divide-by-zero,arithmetic overflow,array access out of bounds,null object reference,file not found。每种异常类型都是一个类，分为System.SystemException和System.Appli

1.封闭对象的原理1）良好的封装能减少耦合2）类的内部实现可以自由修改3）类具有清晰的对外接口实现封装的方式之一是数据隐藏，使用访问限制修饰符。包括Public、Protected internal、Internal、protected、private等。属性和索引器也用来封装类的细节，并提供公用接口给该类的用户。在C#中，默认的访问限制是Private。2.继承性一个类可以有能力

 计算机程序运行方式的三个发展阶段：1.单一·本地 可执行文件时代。2.分散的、基于DLL文件的时代。3.基于虚拟机的应用程序执行模式。Managed Execution 受控的执行或托管的执行。主要起到可移植性及安全执行的作用CLR＝Common Language Runtime。FxCL＝Framework Class Library。无论自己的应用程序还是通用的类库都运行在C

 由于以前是做VB6开发的，因此在接触.net framework之后首选的学习语言就是VB.net。尽管和过去相比这个VB.net已经是有点不太认识的感觉了，但毕竟里面的一些语法、关键字还是比较亲切的，觉得可能用起来简单一点。 几个月过去了，也基本上可以用VB.net实现小型的系统和ASP.net网站了。但就是感觉一直不爽，上网查资料也好，买书也好，许多讲框架的都是以C#为语言描述的，虽然也能看

1)分部类（Partial Classes）C#2.0可以将类、结构或接口的定义拆分到两个或多个源文件中，在类声明前添加partial关键字即可。在处理大型项目时使一个类分布于多个独立文件中可以让多位程序员对该类进行处理。使用自动生成的源时无需重新创建源文件便可以将代码添加到类中。Visual Studio在创建Windows窗体、Web窗体时都使用此方法。无需编辑VisualStudio所创

C#简洁快速，容易上手，用起来很顺。打比方，C#更像邻家MM，容易接近，C++更象女博士，受人尊重。VB.net更象灌篮高手，什么都能做，什么都不缺。1.构造函数类中特殊的方法，多用于初始化实例的数据成员。在实例化new时被自动调用。特点：函数名与类名总是相同，没有返回值。通过重载（Overload 参数列表不同），构造函数可以任意多。构造函数之间可以相互调用。可使用访问修饰符。如果是Prot

ADO.net体系结构Connection对象：string sConnect;sConnect = string.format("Provider={0};DataSource={1}{2}","Microsoft.Jet.OLEDB.4.0;",System.AppDomain.CurrentDomain.BaseDirectory,"Sale.mdb");MSA.OLEDbconne

软件架构的定义 软件架构是一系列声明，描述软件组件，并将系统功能指派给组件。架构描述组件的技术结构、约束、特性和组件之间的接口。架构是系统蓝图，是结构的高级隐式规划。 SOA的定义 SOA是一个软件架构，它包含四个关键概念：应用程序前端、服务、服务库和服务总线。一个服务包含一个合约、一个或多个接口以及一个实现。 SOA全部概念的重心是定义业务基础结构。服务是SOA的主要战略性实体。SO

Builder模式的缘起假设创建游戏中一个房屋House设施，该房屋的构建由几部分组成，且各个部分要富于变化。如果使用最直观的设计方法，每一个房屋部分的变化都会导致房屋构建的重新修正……其实房屋构造的抽象部分并没有变化。这时，构造房子的算法是稳定的，系统构建中的高层抽象部分是变化比较小的。Builder模式动机（Motivation）在软件系统中，有时候面临着“一个复杂对象”的创建工作

引言：new的问题常规的对象创建方法是：Road road = new Road();这种做法存在实现依赖，不能应对“具体实例化类型”的变化。其解决方法是封装变化点——哪里有变化就封装哪里。（其潜台词是：如果没有变化，就不需要额外的封装！）。使用OO设计框架中，有一个主流的东西不变（或倾向于变化慢），其它东西变化（或倾向于变化快），这些变化点才需要封装。既然变化点在“对象创建”，我

前言：OO不能拒绝变化，而是要隔离变化。使得变化造成的影响在一个可以接受的范围内。动机（Motivation）：在软件系统中经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性以及良好的效率。如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例呢？这应该是类设计者的责任，而不是使用者的责任。我们不能让使用者保证只“New”一个对象……意图（Inte

以下内容为学习李建忠老师之《C#面向对象设计模式纵横谈》系列课程的第一讲之笔记。每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。　　　　　　　　　　　　　——Christopher　Alexander设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中、特定场景下，类与相互通信的对象之间常见的组织关系。包括它们

 以下内容摘自MSDN简介.NET Framework 2.0 允许您创建和访问在各应用程序执行会话之间保持的值。这些值称为设置。设置可以表示用户首选项，也可表示应用程序需要使用的宝贵信息。例如，可以创建一系列设置来存储应用程序配色方案的用户首选项。也可以存储指定应用程序所使用数据库的连接字符串。通过设置不但可以保持对于代码外部的应用程序至关重要的信息，而且还可以创建分别存储各用户首选项的