假设有一个音乐盒工厂，购买音乐盒的客人不用知道音乐盒是如何制作的，他只要知道如何播放音乐盒就可以了，以 UML 类别图来表示以上的概念：
如上图所示的，MusicBoxDemo代表了客户的角色，它只依赖于IMusicBox介面，而不关心特定的实作，实际如何产生IMusicBox的实例由MusicBoxFactory完成，以一个简单的程式来实现上面这个UML类别图：
- IMusicBox.java
public interface IMusicBox {
public void play();
}
- PianoBox.java
public class PianoBox implements IMusicBox {
public void play() {
System.out.println("拨放钢琴音乐:)");
}
}
- ViolinBox.java
public class ViolinBox implements IMusicBox {
public void play() {
System.out.println("拨放小提琴音乐^_^");
}
}
- MusicBoxFactory.java
public class MusicBoxFactory {
public static IMusicBox createMusicBox(String name)
throws InstantiationException,
IllegalAccessException,
ClassNotFoundException {
// 这边使用的是Java的Reflection机制来产生实例
// 不过客户端不用管啦
// 以后就算改变了这边的程式，客户端程式是不用更改的
return (IMusicBox) Class.forName(name).newInstance();
}
}
- MusicBoxDemo.java
public class MusicBoxDemo {
public static void main(String[] args) throws Exception {
playMusicBox(MusicBoxFactory.createMusicBox("PianoBox"));
playMusicBox(MusicBoxFactory.createMusicBox("ViolinBox"));
}
public static void playMusicBox(IMusicBox musicBox) {
musicBox.play();
}
}
由于客户端只依赖于IMusicBox介面，所以即使您日后改变了createMusicBox()中的实作方式，对客户端是一点影响也没有的。
来看看Simple Factory的类别结构：
客户只要面对Factory，客户依赖于产品介面，产品的具体实作是可以与客户隔开的，它们也是可以抽换的。
==============================================================================
本文转自被遗忘的博客园博客，原文链接：http://www.cnblogs.com/rollenholt/archive/2012/04/23/2466949.html，如需转载请自行联系原作者
