作者：Game_over 来源：博客园 酷勤网收集 2008-02-28
摘要
高手自言自语：是啊，你不受GOF设计模式的束缚，不强迫自己往他给定的UML类图上靠，而思想上却是相通的，小伙儿有前途。听了高手这一顿白话，我信心倍增。高手看我信心爆膨，说：别高兴的太早，刚才客户又有新的需求了，这回看你能不能瞎猫碰到死耗子身上，给我整出来。
上回说到Command的雏形被高手改过之后，高手让我再对代码进行一下重构和完善，并且还特意嘱咐不要出现那么多的字符串。饿滴神啊，该怎么办呢？
外事不决问Google，果然，有办法了：
我用一个配置文件，把用户输入的命令和实际的Command类一一对应，然后利用反射实例化这个类。
好，那就开始做吧。
首先创建app.config文件，这个是工程默认会读取的，就不用自己解析XML了，这个文件里面是这样的：
Code
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="echo" value="Command.EchoCommand"/>
<add key="exit" value="Command.ExitCommand"/>
</appSettings>
</configuration>
指令跟对应的类是一一对应的，然后再创建一个Class，用来读取配置文件，生成对应的实例，这个类起什么名字好呢？
它会生成很多不同类型的实例，好，暂且就叫它CommandFactory吧，然后给它一个静态方法，一个参数，返回值就是ICommand。Code
public static ICommand getCommand(String comName)
{
string comClsName = ConfigurationSettings.AppSettings[comName];
if (comClsName != null)
{
Type type = Type.GetType(comClsName);
_cmd = (ICommand)Activator.CreateInstance(type);
}
else
{
_cmd = new UnknownCommand();
}
return _cmd;
}
我都有点儿佩服我自己了，一个很好的解决办法，嗯，厉害！！！
Processor类也需要修改，以前是只能添加新的Command，但是如果用户第二次输入同样指令，就不应该添加，而应该是替换了。
到现在，最终的主方法已经是这样子的了：Code
String command = "";
Processor p = new Processor();
while (true)
{
command = Console.ReadLine();
String cmdName = command.Split(SPACE.ToCharArray())[0];
ICommand cmd = CommandFactory.getCommand(cmdName);
if (command.IndexOf(SPACE) == -1)
{
cmd.setRequest(command);
}
else
{
cmd.setRequest(command.Substring(command.IndexOf(SPACE) + 1));
}
p.setCommand(cmdName, cmd);
p.request();
}
比以前简洁了不少，而且每那么多的if else 和常量了，我的工作完成了。
高手看我沾沾自喜的样子，走过来，说：做完了，我看看。
看了一眼，又说：你比我当年不差啊，看过设计模式，是吧。
我老老实实的说：没看过，我就是觉得这么做应该就是比较好的做法，也不知道什么模式不模式的。
高手自言自语：是啊，你不受GOF设计模式的束缚，不强迫自己往他给定的UML类图上靠，而思想上却是相通的，小伙儿有前途啊。
听了高手这一顿白话，我信心倍增。
高手看我信心爆膨，说：别高兴的太早，刚才客户又有新的需求了，这回看你能不能瞎猫碰到死耗子身上，给我整出来。
我说：没问题。
不过，过了三分钟，我满面愁容的坐在电脑前，不知道如何下手。
代码：http://www.cnblogs.com/Files/game-over/Command2.rar
外事不决问Google，果然，有办法了：
我用一个配置文件，把用户输入的命令和实际的Command类一一对应，然后利用反射实例化这个类。
好，那就开始做吧。
首先创建app.config文件，这个是工程默认会读取的，就不用自己解析XML了，这个文件里面是这样的：
Code<?xml version="1.0" encoding="utf-8" ?><configuration> <appSettings> <add key="echo" value="Command.EchoCommand"/> <add key="exit" value="Command.ExitCommand"/> </appSettings></configuration>指令跟对应的类是一一对应的，然后再创建一个Class，用来读取配置文件，生成对应的实例，这个类起什么名字好呢？
它会生成很多不同类型的实例，好，暂且就叫它CommandFactory吧，然后给它一个静态方法，一个参数，返回值就是ICommand。
Codepublic static ICommand getCommand(String comName){ string comClsName = ConfigurationSettings.AppSettings[comName]; if (comClsName != null) { Type type = Type.GetType(comClsName); _cmd = (ICommand)Activator.CreateInstance(type); } else { _cmd = new UnknownCommand(); } return _cmd;}我都有点儿佩服我自己了，一个很好的解决办法，嗯，厉害！！！
Processor类也需要修改，以前是只能添加新的Command，但是如果用户第二次输入同样指令，就不应该添加，而应该是替换了。
到现在，最终的主方法已经是这样子的了：
CodeString command = "";Processor p = new Processor();while (true){ command = Console.ReadLine(); String cmdName = command.Split(SPACE.ToCharArray())[0]; ICommand cmd = CommandFactory.getCommand(cmdName); if (command.IndexOf(SPACE) == -1) { cmd.setRequest(command); } else { cmd.setRequest(command.Substring(command.IndexOf(SPACE) + 1)); } p.setCommand(cmdName, cmd); p.request();}比以前简洁了不少，而且每那么多的if else 和常量了，我的工作完成了。
高手看我沾沾自喜的样子，走过来，说：做完了，我看看。
看了一眼，又说：你比我当年不差啊，看过设计模式，是吧。
我老老实实的说：没看过，我就是觉得这么做应该就是比较好的做法，也不知道什么模式不模式的。
高手自言自语：是啊，你不受GOF设计模式的束缚，不强迫自己往他给定的UML类图上靠，而思想上却是相通的，小伙儿有前途啊。
听了高手这一顿白话，我信心倍增。
高手看我信心爆膨，说：别高兴的太早，刚才客户又有新的需求了，这回看你能不能瞎猫碰到死耗子身上，给我整出来。
我说：没问题。
不过，过了三分钟，我满面愁容的坐在电脑前，不知道如何下手。
代码：http://www.cnblogs.com/Files/game-over/Command2.rar