设计模式——行为型模式之 Command 命令模式

最近对设计模式的理解都是从李建忠老师的讲解里获得的。李建忠老师有句话说得很对：对中国的计算机教育了解得越多，就越会感觉到中国的计算机教育是多么的失败。我对这句话深信不疑，中国的程序员们，一群聪明的孩子，就是这群聪明的孩子，被教育成了一个个重复着别人的重复劳动的可怜的孩子。说白了，我们每天都是在别人为我们设定的框架中工作，不能接触到对硬件操作的底层每每让我感到很不爽。可是设计模式不一样，这是一个程序员的内功，在OO的世界中，掌握了DESIGN PATTERNS无疑如武林世界中掌握了九阳真经，再练其他的功夫简直易如反掌，像乾坤大诺伊什么的，很爽。。。。。。

关于design patterns之comment模式（命令模式）的我的理解是下面这样子的。本着知其然，知其所以然的原则，我们来看看一种会碰到Command模式的情况：

class  Document() ... {
public void showTxt()...{}
public void reDo()...{}
public void unDo()...{}
}

class  Picture() ... {
publc void showPic()...{}
public void reDo()...{}
public void unDo()...{}
}

class  Application() ... {

Document document = new Document();
document.showTxt();

Picture picture = new Picture();
picture.showPic(); 

document.reDo();
picture.reDo();

document.unDo();
picture.unDo();

//......................


}

如程序中所见，我们可能在主程序中队多个类的对象进行命令操作。当类一多起来，甚至在主程序中加上一定的业务逻辑（比如在主程序中将每次操作命令输出到控制台）的时候，主程序里的代码将变得非常复杂和混乱，还有一个最主要的问题会出现：客户程序和各个类之间出现紧耦合：我们可以想象一下，如果我们现在变化以下document类中的showTxt方法为 public void showChineseTxt(){}这时候客户端代码需要做什么变动呢？肯定的，他也要做出相应的改变来应对这种变动，这就是代码的紧耦合。我们给出一种解决方案：

public  Interface Command()
... {
public void show()...{}
public void reDo()...{}
public void unDo()...{}
}

class  Document() : Command ... {
public void show()...{}
public void reDo()...{}
public void unDo()...{}
}

class  Picture() : Command ... {
publc void show()...{}
public void reDo()...{}
public void unDo()...{}
}

class  Application() ... {

ArrayList<Command> list;

public void show()...{
  foreach(Command c in list)...{
  c.show();
}
}
public void reDo()...{
foreach(Command c in list)...{
 c.reDo();}
}

//......................


}

这样一来，起码客户程序中的代码不会那么杂乱无章了，但是还有一个问题，单独的类中的方法必须遵循接口中的方法的定义，灵活性消失，耦合实际上还是存在，于是给出下面的方案：

class  Document() ... {
public void showTxt()...{}
public void reDoTxt()...{}
public void unDoTxt()...{}
}

class  Picture() ... {
publc void showPic()...{}
public void reDoPic()...{}
public void unDoPic()...{}
}

publci Interface Command() ... {
public void show()...{}
public void reDo()...{}
public void unDo()...{}
}
class  DocumentCommand() : Command ... {
Document document;
public Document(Document document)...{
this.document = document;}
public void show()...{
document.showTxt();}

public void reDo()...{
document.reDoTxt();}

public void unDo()...{
document.unDoTxt();}
}

public  PictureCommand ; Command() ... {

//类似的定义
}

class  Application() ... {

Stack<Command> stack;
foreach(Command c in stack)...{
c.show();
c.reDo();
c.unDo();
}
//......................


}

这样我们将客户程序与类之间的依赖关系转移到了客户程序与抽象借口以及类与抽象接口之间的依赖关系。本来是A依赖于B，现在变成了A依赖于C和B依赖于C。