背景：

因为工作和学习的需要，我从网上下载了很多代码，但是代码越多，管理这些代码就越麻烦。问题主要有以下几点：

1、工作中急需的一些代码我以前写过或是我几个月前曾经下载过，但是一时就是找不到。

2、从网上下载需要的代码相当费时间，而且很难找到合适的。特别是做winform界面时，那些具有特定效果的控件的代码相当难找。

3、重装系统后，有些代码会被当作垃圾处理掉。

为了解决这些问题，也为了更好的学习，我想趁空闲时间编一个属于自己的代码管理器。我把自己的代码管理器的特点归纳为：快速精确的查找和快速的复制粘贴。下面是我和几位同行聊天后确定的一些需求，希望大家多多补充。

需求：

1、类别管理（对代码进行分类）

1）、类别可以增加、删除、重命名

2）、类别与文件是多对多关系

3）、 类别前有图标，显示类别属性，图标可以更改

4）、支持文件夹的导入

2、 文件（存放代码的文件）管理

1）、 有标题、文件大小、修改时间、重要程度等属性

2）、标题前有图标，显示文件类型，图标可以更改

3）、文件可以增加、删除，属性可以编辑

4）、支持ClipBoard模式粘贴

        ClipBoard模式：对指定的文件夹定义快捷键。按下快捷键，弹出上下文菜单，进行文件选择性粘贴。

5）、 重要程度用图标显示

6）、有导入导出功能

7）、可以按时间、重要程度、喜好程度对文件进行归类

3、 代码管理

1）、有代码、例子、评注部分

        评注部分可以写一些代码的相关信息。

2）、代码和例子部分支持关键字高亮显示，评注部分允许存放图片

3）、 代码的复制、粘贴功能佷重要，必须提供快捷键

4）、支持AutoText模式的复制粘贴

         AutoText模式：先对一些代码段定义几个字母，然后通过快捷键开启该模式，在文本编辑器（普通的记事本或vs2005等）输入预先定义的几个字母，实现代码段的快速粘贴。

5）、代码需要有提示功能，在不打开代码时就能知道它的用途

6）、有些代码最好可以看到执行效果（这个可能比较难实现）

4、 查找功能

1）、可以对文件和代码内容进行查找

2）、支持正则表达式查找

3）、 可以在系统中嵌入浏览器进行上网查找

4）、支持Auto Text模式进行上网查找

        Auto Text模式：先对一些URL定义几个字母，然后通过快捷键开启该模式，在文本编辑器中输入预先定义的几个字母，实现快速上网。

5）、支持语言、方法、类、项目等分类进行上网查找，最好有自己的代码搜索引擎。

5、方便的复制粘贴功能

1）、支持AutoText模式的快速粘贴

2）、 支持ClipBoard模式粘贴

6、 导入导出

1）、支持多个文件同时导入

2）、 支持单个文件导出

3）、导入代码时，支持项目和代码的关联

4）、 支持导出时格式转换

7、 其他

1）、支持多种语言的高亮显示

2）、 支持语言的转换功能

3）、对快捷键进行管理，可以自定义快捷键

4）、不能用不提供源代码的第三方控件，该软件本身就应该是一个良好的代码库。

5）、采用CS结构。

最后，欢迎大家提出各种需求或好的建议，过几天我还会编一个简单的界面，方便大家提出更明确的需求。但是那些谈及这类软件已有，不用再编的言论将不予理睬。

结构：

例子：

假设你有一套杀手级的家庭影院系统，内含DVD播放器、投影仪、自动屏幕、环绕立体声等。那么当你想看一部DVD时，需要做哪些事情呢（用最土的方式）？

1、将灯光调暗；

2、放下屏幕；

3、打开投影仪；

4、将投影仪的输入切换到DVD；

5、将投影仪设置成宽屏模式；

6、打开功放；

7、将功放的输入设置为DVD；

8、将功放设置为环绕立体声；

9、将功放音量调到中；

10、打开DVD播放器；

11、开始播放DVD。

我想如果每次看DVD时都要进行这样一番折腾，那我宁愿不看了。上面的操作暴露了哪些问题呢？

1、操作麻烦。具体体现在打开DVD、关闭DVD、改听CD或者广播。

2、升级麻烦（就是耦合度太大）。如果我要升级系统，那么我还必须重新学习另一套操作流程。

那么这些问题如何解决呢？

使用外观模式，新建一个门户类（或管理类），暴露出一些方法，在这些方法里对这些子系统进行调用（这里的子系统具体指灯光、屏幕、投影仪、功放、DVD等）。具体代码很简单，略。

外观模式的优点：

1、对接口进行了简化，方便客户使用。

2、可以实现客户与子系统解耦，易于维护。

缺点：

1、多了一个包装类，可能导致复杂度和开发时间的增加，并降低运行时的性能。

值得注意的地方：

1、外观模式对接口进行了简化，但这并不意味着对子系统进行彻底封装。如果有必要，这些子系统的接口还可以继续暴露给客户，这就是所谓的高级功能（或称为自定义）。

2、外观模式不能新增功能，但他可以将某些功能按次序执行。例如先打开DVD，后播放DVD。

3、子系统与外观不是一对一关系，是多对多关系。一个子系统可以拥有多个外观，一个外观可以调用多个子系统。

4、外观模式与适配器模式的区别不是包装的类的多少，而是意图不一样。适配器模式也可以包装很多类，但他的意图是改变接口，符合客户的期望；外观模式是将接口进行简化，方便使用。

意图：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。

结构：

例子：这次我们将设计一个家电自动化遥控器的ＡＰＩ

需求分析：

遥控器的图：

１）、遥控器上具有七个可编程的插槽、七个开关按钮和一个整体撤销按钮。

２）、通过创建一组ＡＰＩ，使插槽可以控制一个或一组家电装置，这些装置指电灯、电风扇、热水器等。

３）、插槽还可以控制未来可能出现的家电装置。

４）、整体撤销按钮具有撤销上一个命令的功能。

初步思考：

１）、我们将设计一系列类，这些类都具有ＯＮ（）和Ｏｆｆ（）方法。

２）、当遥控器上的ｏｎ或ｏｆｆ开关被按下时，某些类的ｏｎ或ｏｆｆ方法被调用，进而控制家电装置，但这些被调用的类是可以被改变的（因为插槽上的东西可以改变）。

３）、当ｏｎ或ｏｆｆ开关被按下时，如果我们通过ｉｆ－－ｅｌｓｅ语句加以选择判断，那么第三点需求我们将难以满足。

４）撤销功能如何实现，上一个按钮是什么？针对的是哪一个装置？

进一步思考：

这次设计中不变的是遥控器（或者说是遥控器的按钮），变化的是家电装置，例如第一排开关可以控制电灯，也可以控制电风扇，或者未来可能出现的家电。所以我们需要对遥控器和家电装置进行解耦。此时我们想到了命令模式：遥控器（或者说遥控器上的按钮）就是命令的请求者，家电装置就是命令的执行者，我们所要做的就是将命令的请求者和命令的执行者解耦。

具体的过程：

１）、客户创建命令。

２）、客户将命令的执行者封装进命令对象里。

３）、命令的请求者调用命令。

４）、命令的执行者执行命令。

下面我们实现只有一组开关按钮的遥控器，类图如下：

代码如下：

 1class RemoteLodder
 2    {
 3        static void Main(string[] args)
 4        {
 5            SimpleRemoteControl remoteControl = new SimpleRemoteControl();
 6            Light light = new Light();
 7            LightOnCommand lightOnCommand = new LightOnCommand(light);
 8            remoteControl.SetCommand(lightOnCommand);
 9            remoteControl.ButtonWasPressed();
10            Console.ReadLine();
11        }
12    }
13 public class Light
14    {
15        public void On()
16        {
17            Console.WriteLine("Light is on");
18        }
19
20        public void Off()
21        {
22            Console.WriteLine("Light is off");
23        }
24    }
25public class LightOnCommand : Command
26    {
27        Light light;
28
29        public LightOnCommand(Light paramLight)
30        {
31            this.light = paramLight;
32        }
33
34        public void Execute()
35        {
36            light.On();
37        }
38    }
39public interface Command
40    {
41         void Execute();
42    }
43public class SimpleRemoteControl
44    {
45        Command slot;
46
47        public void SetCommand(Command paramCommand)
48        {
49            this.slot = paramCommand;
50        }
51
52        public void ButtonWasPressed()
53        {
54            slot.Execute();
55        }
56    }

注释：命令的请求者：SimpleRemoteControl
　　　命令的执行者：Light
　　　命令接口：Command
　　　具体的命令：LightOnCommand　　
　　　客户（封装命令的）：RemoteLodde　　
我们的遥控器共有七个插槽，可以用数组来实现，这里不写了。撤销按钮的功能可以通过栈来实现（对Command进行入栈，出栈即可）。
补充：
１）NoCommand模式
代码：

1public class NoCommand : Command
2    {
3        public void Execute()
4        {
5        }
6    }

 1public class MacroCommand:Command
 2    {
 3        List<Command> commands;
 4
 5        public MacroCommand(List<Command> commands)
 6        {
 7            this.commands = commands;
 8        }
 9
10        public void Execute()
11        {
12            foreach (Command command in commands)
13            {
14                command.Execute();
15            }
16        }
17    }

一、操作符优化

1、IN 操作符

用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。但是用IN的SQL性能总是比较低的，从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别：

ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。

推荐方案：在业务密集的SQL当中尽量不采用IN操作符，用EXISTS 方案代替。

2、NOT IN操作符

此操作是强列不推荐使用的，因为它不能应用表的索引。

推荐方案：用NOT EXISTS 方案代替

3、IS NULL 或IS NOT NULL操作（判断字段是否为空）

判断字段是否为空一般是不会应用索引的，因为索引是不索引空值的。

推荐方案：用其它相同功能的操作运算代替，如：a is not null 改为 a>0 或a>’’等。不允许字段为空，而用一个缺省值代替空值，如申请中状态字段不允许为空，缺省为申请。

4、> 及 < 操作符（大于或小于操作符）

大于或小于操作符一般情况下是不用调整的，因为它有索引就会采用索引查找，但有的情况下可以对它进行优化，如一个表有100万记录，一个数值型字段A，30万记录的A=0，30万记录的A=1，39万记录的A=2，1万记录的A=3。那么执行A>2与A>=3的效果就有很大的区别了，因为A>2时ORACLE会先找出为2的记录索引再进行比较，而A>=3时ORACLE则直接找到=3的记录索引。

5、LIKE操作符

LIKE操作符可以应用通配符查询，里面的通配符组合可能达到几乎是任意的查询，但是如果用得不好则会产生性能上的问题，如LIKE ‘%5400%’ 这种查询不会引用索引，而LIKE ‘X5400%’则会引用范围索引。

一个实际例子：用YW_YHJBQK表中营业编号后面的户标识号可来查询营业编号 YY_BH LIKE ‘%5400%’ 这个条件会产生全表扫描，如果改成YY_BH LIKE ’X5400%’ OR YY_BH LIKE ’B5400%’ 则会利用YY_BH的索引进行两个范围的查询，性能肯定大大提高。

6、UNION操作符

UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION。如：
select * from gc_dfys
union
select * from ls_jg_dfys
这个SQL在运行时先取出两个表的结果，再用排序空间进行排序删除重复的记录，最后返回结果集，如果表数据量大的话可能会导致用磁盘进行排序。

推荐方案：采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。

select * from gc_dfys
union all
select * from ls_jg_dfys

二、SQL书写的影响

1、同一功能同一性能不同写法SQL的影响。

如一个SQL在A程序员写的为  Select * from zl_yhjbqk

B程序员写的为 Select * from dlyx.zl_yhjbqk（带表所有者的前缀）

C程序员写的为 Select * from DLYX.ZLYHJBQK（大写表名）

D程序员写的为 Select *  from DLYX.ZLYHJBQK（中间多了空格）

以上四个SQL在ORACLE分析整理之后产生的结果及执行的时间是一样的，但是从ORACLE共享内存SGA的原理，可以得出ORACLE对每个SQL 都会对其进行一次分析，并且占用共享内存，如果将SQL的字符串及格式写得完全相同，则ORACLE只会分析一次，共享内存也只会留下一次的分析结果，这不仅可以减少分析SQL的时间，而且可以减少共享内存重复的信息，ORACLE也可以准确统计SQL的执行频率。

2、WHERE后面的条件顺序影响

WHERE子句后面的条件顺序对大数据量表的查询会产生直接的影响。如：
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上两个SQL中dy_dj（电压等级）及xh_bz（销户标志）两个字段都没进行索引，所以执行的时候都是全表扫描，第一条SQL的dy_dj = '1KV以下'条件在记录集内比率为99%，而xh_bz=1的比率只为0.5%，在进行第一条SQL的时候99%条记录都进行dy_dj及xh_bz的比较，而在进行第二条SQL的时候0.5%条记录都进行dy_dj及xh_bz的比较，以此可以得出第二条SQL的CPU占用率明显比第一条低。

3、查询表顺序的影响

在FROM后面的表中的列表顺序会对SQL执行性能影响，在没有索引及ORACLE没有对表进行统计分析的情况下，ORACLE会按表出现的顺序进行链接，由此可见表的顺序不对时会产生十分耗服物器资源的数据交叉。（注：如果对表进行了统计分析，ORACLE会自动先进小表的链接，再进行大表的链接）

三、SQL语句索引的利用

1、操作符优化（同上）

2、对条件字段的一些优化

采用函数处理的字段不能利用索引，如：

substr(hbs_bh,1,4)=’5400’，优化处理：hbs_bh like ‘5400%’

trunc(sk_rq)=trunc(sysdate)， 优化处理：sk_rq>=trunc(sysdate) and sk_rq<trunc(sysdate+1)

进行了显式或隐式的运算的字段不能进行索引，如：ss_df+20>50，优化处理：ss_df>30

‘X’ || hbs_bh>’X5400021452’，优化处理：hbs_bh>’5400021542’

sk_rq+5=sysdate，优化处理：sk_rq=sysdate-5

hbs_bh=5401002554，优化处理：hbs_bh=’ 5401002554’，注：此条件对hbs_bh 进行隐式的to_number转换，因为hbs_bh字段是字符型。

条件内包括了多个本表的字段运算时不能进行索引，如：ys_df>cx_df，无法进行优化
qc_bh || kh_bh=’5400250000’，优化处理：qc_bh=’5400’ and kh_bh=’250000’

四、其他

ORACLE的提示功能是比较强的功能，也是比较复杂的应用，并且提示只是给ORACLE执行的一个建议，有时如果出于成本方面的考虑ORACLE也可能不会按提示进行。根据实践应用，一般不建议开发人员应用ORACLE提示，因为各个数据库及服务器性能情况不一样，很可能一个地方性能提升了，但另一个地方却下降了，ORACLE在SQL执行分析方面已经比较成熟，如果分析执行的路径不对首先应在数据库结构（主要是索引）、服务器当前性能（共享内存、磁盘文件碎片）、数据库对象（表、索引）统计信息是否正确这几方面分析。

结构：

例子：

下面我们以星巴兹（Starbuzz）的订单系统为例加以说明。

需求分析：

1）、星巴兹的饮料（Beverage）种类繁多，主要有HouseBlend、DarkRoast、Decaf、Espresso。

2）、星巴兹的调料很多，主要有Steamed Milk、Soy、Mocha、Whip。

3）、星巴兹的饮料价格是根据饮料的基础价和所加入的调料的价格相加得到。

错误设计：

根据以上的简单分析，第一种类图设计出炉：

其中getDescription（）用来描述饮料，cost（）用来计算价格。

显而易见，这个类图设计的最大缺点就是类太多，系统难以维护。所以我们需要另外的解决方案，而且新方案必须避免“类爆炸”。此时我们想到了实例变量和继承。先从Beverage基类下手，加上实例变量代表是否加上调料（Steamed Milk、Soy、Mocha、Whip等），Beverage基类的cost（）计算调料的价钱，而各种具体的饮料（HouseBlend、DarkRoast、Decaf、Espresso等）的cost（）将把基础饮料的价钱和调料的价钱相加得到饮料的价钱。由此可以设计出第二种类图。

对这个类图设计的评价：如果需求不再变化，那么这个类图设计没有错；但是需求发生了变化，这个设计就会难以招架。经过进一步的分析，我们发现部分需求被我们遗漏了。

新增加的需求：

1）、调料的价格可能发生变化。

2）、调料的种类可能发生变化。

3）、饮料的种类可能增加，不只HouseBlend、DarkRoast、Decaf、Espresso四种。

4）、顾客可能在一种饮料里加双份的同种饮料。

显然，第二种类图设计难以满足新的需求，而且对新增加的饮料而言，有可能存在不适合的调料。例如，茶子类将继承hasWhip（）（加奶泡）等方法。因此，我们应该对类图设计进行改进。此时我们想到了装饰者模式，那么如何应用装饰者模式呢？

以装饰者模式构造饮料订单：

1）、以DarkRoast对象开始。

2）、顾客想要Mocha，所以建立一个Mocha对象，并用它将DarkRoast对象包装起来。

3）、顾客也想要Whip，所以需要建立一个Whip装饰者，并用它将Mocha对象包起来。

4）、现在，该是为顾客算钱的时候了。通过最外圈装饰者（Whip)的cost（）就可以办得到。Whip的cost（）会先委托它装饰的对象（Mocha）计算出价钱，然后再加上Whip的价钱。

根据以上的分析，应用装饰者模式，我们可以打造一个全新的类图。

第三种类图设计（正确的类图）：

部分代码为：

 1public class DarkRoast : Beverage
 2    {
 3        public DarkRoast()
 4        {
 5            description = "Dark Roast";
 6        }    
 7        public override double Cost()
 8        {
 9            return 1.22;
10        }
11    }
12public class Mocha : CondimentDecorator
13    {
14        Beverage myBeverage;
15        public Mocha(Beverage paramBeverage)
16        {
17            this.myBeverage = paramBeverage;
18        }
19
20        public override string GetDescription()
21        {
22            return myBeverage.GetDescription() + ",Mocha";
23        } 
24    
25        public override double Cost()
26        {
27            return 0.5 + myBeverage.Cost();
28        }
29    }
30class StarbuzzCoffee
31    {
32        static void Main(string[] args)
33        {
34            Beverage myBeverage = new Espresso();
35            Console.WriteLine(myBeverage.GetDescription() + " $" + myBeverage.Cost());
36
37            Beverage myBeverage2 = new DarkRoast();
38            myBeverage2 = new Mocha(myBeverage2);
39            myBeverage2 = new Mocha(myBeverage2);
40            myBeverage2 = new Whip(myBeverage2);
41            Console.WriteLine(myBeverage2.GetDescription() + " $" + myBeverage2.Cost());
42
43            Console.ReadLine();
44        }
45    }

 装饰模式的适用情况：

1）、需要扩展一个类的功能，或给一个类增加附加责任。

2）、需要动态地给一个对象增加功能，这些功能可以再动态地撤销。

3）、需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。

使用装饰模式主要有以下的优点：

1）、装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。

2）、通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

使用装饰模式主要有以下的缺点：

由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

参考文献： 

《Head.First设计模式》

  吕震宇  设计模式系列

源代码下载：/Files/wxj1020/StarbuzzCoffee.rar

结构：

例子：

下面以模拟气象站系统来加以说明。

需求分析：

该系统的需求如下：

1、气象站能够追踪目前的天气状况，包括温度、湿度、气压、

2、气象站能够提供三种布告板，分别显示目前天气状况、气象统计和简单的预报。

3、布告板上的数据必须实时更新。

4、气象站必须提供一组API，供其他开发人员开发其他的布告板。

设计部分：

基于以上需求，该系统可以设计成3部分：气象站（获取实际气象数据的物理装置）、WeatherData对象（追踪来自气象站的数据，并更新布告板）和布告板（显示目前的天气状况给用户看）。效果图如下：

错误的类图设计（即没有学过设计模式时的第一感觉）可能如下：

相应的代码实现部分：

 1public void MeasurementsChanged()
 2        {
 3            temperature = this.GetTemperature();   // 获得温度
 4            humidity = this.GetHumidity();         // 获得湿度
 5            pressure = this.GetPressure();         // 获得气压 
 6
 7            MyCurrentConditionsDisplay.Update(temperature, humidity, pressure);     // 更新目前天气状态板
 8            MyStatisticsDisplay.Update(temperature, humidity, pressure);            // 更新气象统计板
 9            MyForcastDisplay.Update(temperature, humidity, pressure);               // 更新天气预报板            
10        }

这个类图设计的缺点：

1）、该设计是针对具体实现编程，而非针对接口。

2）、对于每个新的布告板，我们都得修改代码。

3）、我们无法在运动时动态得增加或删除布告板。

4）、我们尚未封装改变的部分。

那么如何改正这些缺点呢？

首先我们必须明白这些缺点的根源在哪里。很明显，我们在类图设计时依赖关系错了，应该依赖倒置。CurrrentConditionsDisplay类、StatisticsDisplay类和ForcastDisplay类应该依赖WeatherData类，而不是相反,这样就可以起到解耦的目的。

其次，CurrrentConditionsDisplay类、StatisticsDisplay类和ForcastDisplay类都有一个Update（）方法，因此应该提炼一个接口，这样可以实现“针对接口编程”，使代码更加灵活，也方便其他开发人员开发其他的布告板。

进一步思考：

1）、改正这些缺点后，我们的类图已经与观察者模式的结构有点类似了。

2）、我们的气象站系统的最大问题其实就是一对多的依赖引起的，而观察者模式正是解除一对多关系的不二法门，因此我们有必要采用观察者模式。

采用了观察者模式后设计的类图应该是这样：

WeatherDatea实现ISubject接口，CurrentConditionsDisplay、ForcastDisplay、StatisticsDisplay实现IObserver接口，ISubject调用IObserver，CurrentConditionsDisplay、ForcastDisplay、StatisticsDisplay调用ISubject。

相应的代码实现部分：

 1public class WeatherData : ISubject
 2    {
 3        private float temperature;
 4        private float humidity;
 5        private float pressure;
 6        private List<IObserver> myList = new List<IObserver>();
 7
 8        public void SetWeatherData(float paramTemp, float paramHumidity, float paramPressure)
 9        {
10            this.temperature = paramTemp;
11