原始模型模式
============================================
=============================================package com.Mapking;/*** JAVA设计模式：原型--复制建立对象实例** 先产生Manager的对象实例，* 然后再把UnderlinePen的对象实例MessageBox的对象实例(含名称)注册到Manager的对象实例中.* @author Administrator*/public class Main{ public static void main(String[] args) { //预备阶段 Manager manager = new Manager(); UnderlinePen upen = new UnderlinePen('~'); MessageBox mbox = new MessageBox('*'); MessageBox sbox = new MessageBox('/'); manager.register( "strong message", upen); manager.register( "warning box", mbox); manager.register( "slash box", sbox); //实现产生 Product p1 = manager.create( "strong message"); p1.use( "Hello world."); Product p2 = manager.create( "warning box"); p2.use( "Hello world."); Product p3 = manager.create( "slash box"); p3.use( "Hello world."); }}
==========================================
run:
"Hello world."
~~~~~~~~~~~~
****************
*Hello world.*
****************
////////////////
/Hello world./
////////////////
成功生成（总时间：0 秒）
=============================================
适用：
（1）种类过多无法整合成类时
程序示例出现过下面3种雏形：
a.以'~'把字符串加上下划线;
b.以'*'把字符串加上边框;
c.以'/'把字符串加上边框。
这些例子都属于简单型，虽然雏形只列出3种，只要有心的话还可以多做几种。但是如果全部都要做不同的类，类数量会增加，同时增加程序了程序源代码管理的困难度。
（2）不容易利用类产生对象实例时
在本程序中可能不太明显，不过，你可以想象一下作图的操作。如果把这个操作跟几乎全以鼠标辅助操作的绘图软件联想起来，应该会比较容易理解。
假设有一个表示原来以人工操作方式绘制图形的对象实例，而现在要建立一个完全相同的新对象实例。在这种情形下，利用对象实例复制的方式当然会比从头用类来产生对象实例要简单得多。
（3）希望把框架和所产生的对象实例分开时
程序示例把执行对象实例复制(clone)的部分放在com.mapKing.framework程序包内。
产生对象实例时当然要传递类名给Manager类的create方法，不过这里以"strong message"和"slash box"取代。这可以说是加强广泛应用JAVA语言原本就有的对象实例产生的架构 new Something()的格式，而让框架脱离类名称的束缚。
类名是一种束缚!
话说回来，如果硬把类名塞到程序源代码内会发生什么问题呢？把程序中利用到的类名写在里面不是理所当然的吗？
在这里，要请各位回忆一下面向对象程序设计的几个使用目的，"零件化复用"正是其中之一。
事先把源代码用到的类名写来这个操作，也不见得就是一定错。但是当你写下源代码内所用到的类名的那一刻起，它就无法跟该类分享供你复用了。
当然只要动手修改源代码就可以改掉类名称，不过从"零件化复用"的角度来说，根本不考虑修改源代码。
谈到JAVA，"即使手中只有类文件(.class),可否复用该类?"这个概念相当重要。说到重点了，对，就是"即使没有源文件(.java)，可否予以复用?"。
必须紧密结合在一起的类名写到源代码内是理所当然的，根本不成问题；
真正问题是应该分享独立成零件的类名却被写到源代码里面了。
