设计模式（designer pattern）

撰写程序常有些看似不合理但是又非得完成的需求。举个例子说，现在老板叫你开发一个猜数字游戏，会随机产生0-9的数字，用户输入的数字与随机产生的数字相比，如果相同就显示“猜中了”，如果不同则让用户继续输入数字，直到猜中为止。
这程序有什么难的，相信你现在也可以写出来：

import java.util.Scanner;

public class Guess{
	public static void main(String[] args) {
		Scanner input = new Scanner(System.in);
		int number = (int)(Math.random()*10);
		int guess;
		do{
			System.out.println("输入数字：");
			guess = Scanner.nextInt();
		}while(guess != number);
		System.out.println("猜中了！");
	}
}
	

当你将程序交给老板后，老板皱着眉头说：“我有说要在文本模式下执行这个游戏吗？”你就问了：“请问会在哪个环境下执行呢？”老板说：“还没有决定，也许会用窗口程序，不过改成网页也不错，下个星期开会讨论一下。”你问：“那可以下个星期讨论好了我再来写吗？”老板说：“不行！”你：“……”

这个例子好笑吗？在团队合作、多个部门开发程序时，有很多时候，你不能只是为了等另外一个部门把程序操作出来，也许另外一个部门要3个月才能完成，难道你们这个部门要空转3个月？有些需求无法确定，却要撰写出程序的例子太多了。

其实有些看似不合理的需求，可以通过设计来解决。以上面的例子来说，取得用户输入、显示结果的环境未定，但你负责的这部分还是可以先操作的。例如：

public abstract class GuessGame {
	public void go(){
		int number = (int)(Math.random()*10);
		int guess;
		do {
			print("输入数字：");
			guess = nextInt();
		}while (guess != number);
		println("猜中了");
	}
	public void println(String text){
		print(text+"\t");
	}
	
	public abstract void print(String text);
	public abstract int nextInt();
}

这个类的定义不完整，print()、println()与nextInt()都是抽象发放，因为老板还没有决定在哪个环境执行游戏，所以如何显示输出、取得用户输入值就不能操作。可以先操作的是猜数字的流程，虽然是抽象方法，但在go()方法中，还是可以调用。

等到下个星期开会决定，还是在文本模式下执行游戏，你就再撰写ConsoleGame，继承抽象类GuessGame，操作当中的抽象方法即可。：

public class ConsoleGame extends GuessGame {
	private Scanner input = new Scanner(System.in);

	@Override
	public void print(String text) {
		System.out.print(text);
	}

	@Override
	public int nextInt() {
		return input.nextInt();
	}

}

实际上创建出ConsoleGame实例，执行go()方法过程中调用到print()、nextInt()或println()等方法时，都是执行ConsoleGame中定义的流程，完整的猜数游戏就操作出来了。例如：

public class Guess{
	public static void main(String[] args) {
		GuessGame game = new ConsoleGame();
		game.go();
	}
	
}

一个执行结果如下：

输入数字：5
输入数字：4
输入数字：3
输入数字：2
猜中了	

设计上的经验，称为设计模式（Design Pattern），如果你对其他设计模式有兴趣，欢迎持续查看本博客更新内容。