我的第一次根本不需要半个小时，就写出了能适应各种打折的情况的代码。然而它是面向过程的。
然后强迫自己用面向对象的思想，写出了第二个代码，写的过程中，我真的天真地设想，正常收费的一个类，打折的一个类，突然想到书中的一句话：并不是类越多越好，才悬崖勒马，打折的只写一个类。不过，以我的观点，这种用类的代码比面向过程的差多了（初学者与高手的区别就在这里）。
加类后，代码运行结果不对了，我开始找如何在命令行调试的代码，结果找到了cordbg.exe，我计算机上没有安装，从其它人C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin里拷来cordbg.exe与MdbgCore.dll。路径中加入该路径，就可以使用了。编译程序时，csc后面也要加上/debug，这时会生成.pdb文件。
以下列出我有用到的几个命令：
sh
列出最近的几行代码
sh 18
列出18行代码
b 12
设置第12行为断点
del
清除断点
g
执行到断点
n
执行下一步
si
进入代码
p
打印出局部变量的值
其它可以参考：http://pangzi.blogchina.com/blog/377577.html
后来才发现，我在第一章的代码就已经不对了。
简单工厂模式的问题：类多，关系复杂，（父类，各种子类，工厂类，取名我都要想半天），仍然使用switch，参数给的顺序要正确，事实上没有解决如果更新后，要在各个计算机上重新安装的问题。它只是利用定义时使用父类（这样接口相同），然后创建时使用具体子类（这样实现方法不一致），然后实现不改动类，而只增加类。其实不要工厂类也是可以的。写出了代码2-2.cs，不用工厂类。但后来又发现，不用工厂类，造成增加打折类型时，客户端代码要改（一边是已有的打折类型不让更改，另一边是客户端不让更改，要求可真多，总之就是稳定后的东西不允许更改）。最后我还是老实地使用工厂类实现一下看。不过这次要试一下分开编译的可能性。
试的结果为，如果代码分成两个文件来写，第一次要编译基础的类，用如下命令：
csc /target:library 2-32.cs
第二次要编译Main的程序，用如下命令
csc /res:2-32.dll 2-31.cs
如果代码分成三个文件来写，第一次用的命令相同，第二次是要编译工厂类的代码，则要保证第一次的类为PUBLIC性质，然后用如下命令编译第二次
csc /reference:2-32.dll /target:library 2-33.cs
第三次要编译Main，用如下命令
csc /reference:2-32.dll,2-33.dll 2-31.cs
然后，我们现在假设商场要收塑料袋的钱，就是打好折后的钱再加1元，我们改了2-32.cs，用csc /target:library 2-32.cs重新编译，然后再运行2-31，结果就正确了。太高兴了。
各个文件的大小为：2-31.exe 3.5K 2-32.dll 3.5k 2-33.dll 3k
后来，我把三个文件放在一个文件中2-3.cs，再编译成一个exe，大小为4k。
现在不用工厂了，改用策略了，context是环境，上下文的意思，而content才是内容的意思。我开头看不出工厂与策略的区别，以为是文字游戏，后面作者指出不一样的地方，才感觉到策略的好处。即“简单工厂模式需要让客户端认识两个类，父类与工厂类，而策略模式与简单工厂结合的用法，客户端就只需要认识一个类策略类就可以了，耦合更加降低。这使得具体的收费算法彻底地与客户端分离，连算法的父类都不让客户端认识。”。甜头是有了，但实际写起来时才发现上当了，原来，父类的各个属性，都要通过get/set来实现，父类的方法，都要写一个对应的来实现。所以，感觉还不是很好。
策略模式的其它优点，可以理解，但还用不上：一：抽象出父类，就是说，如果先有单独的子类，后面因为要用策略，所以必须产生父类，这样大家就共同推举出了一个父亲。二：每个算法都有自己的类，可以单独测试，（但别人不是也有这种优点吗？）。三：策略模式可以用来封装任何类型的规则。
