李小波

该数据结构用于以替代一些简单的本地缓存系统，并提供快速检索的功能。

业务场景：

用户帐号223，拥有下级帐号223001、223002、2230055、22312345...

用户帐号224，拥有下级帐号224002、2248888...

用户...

223和224，我们暂且叫他为大帐号，后面的都叫小帐号。

当这些小帐号发消息给系统时，需要识别出对应的大帐号，且小帐号的长度不等，不可以检索库表。

假设大帐号已经驻留在内存。

java:

/**
 * 基于二叉树的思路实现的“十叉树”，用于存储一些临时性的数据，并提供一些查询接口
 * @project xframework
 * @date 2013-1-11
 * @version 1.0
 * @author Jason5186@qq.com
 * 
 * @review_history
 * [2013-1-11] create by Jason
 */
public class BinaryTree {
	
	// 树的根结点
	private TreeNode root = null;
	
	/**
	 * 
	 */
	public BinaryTree() {
		// TODO Auto-generated constructor stub
		root = new TreeNode(0);
	}
	
	private class TreeNode {
		
		private int key; 
		private Object value;
		private TreeNode[] nodes = new TreeNode[10];
		
		
		public TreeNode(int key) {
			// TODO Auto-generated constructor stub
			this(key, null);
		}
		
		public TreeNode(int key, Object value) {
			this.key = key;
			this.value = value;
		}	
		
		
		public TreeNode setChildTreeNode(int key, Object value){
			
			synchronized(this){
				TreeNode treeNode = nodes[key];
				if (treeNode == null) {
					nodes[key] = new TreeNode(key);
				}
				getChildTreeNode(key).setValue(value);
			}
			
			return getChildTreeNode(key);
			
		}
		
		public TreeNode setChildTreeNode(int key){
			synchronized(this){
				TreeNode treeNode = nodes[key];
				if (treeNode == null) {
					nodes[key] = new TreeNode(key);
				}
			}
			
			return getChildTreeNode(key);
		}
		
		public TreeNode getChildTreeNode(int key){
			return nodes[key];
		}
		
		public int getKey() {
			return key;
		}
		
		public Object getValue(){
			return value;
		}
		
		public void removeValue(){
			this.value = null;
		}
		
		public void setValue(Object value){
			this.value = value;
		}
		
		public String toString()
		{
			
			return "(" + key + " , " + value + " )";
		}
		
	}
	
	/**
	 * 空返回 true ，否则返回 false . 
	 */
	public boolean isEmpty()
	{
		if (root == null) {
			return true;
		} else {
			return false;
		}			
	}
	
	
	public void TreeEmpty() throws Exception 
	{
		if (isEmpty()) {
			throw new Exception("树为空");
		}
	}
	
	
	
	/**
	 * 查找指定s_key对应的节点
	 * @param s_key
	 * @return TreeNode
	 * @throws Exception
	 */
	public TreeNode search(String s_key) throws Exception 
	{
		
		if (getRoot() == null) {
			throw new Exception("root node is null");
		}
		
		TreeNode treeNode = getRoot();
		
		char[] key_array = s_key.toCharArray();
		
		// 根据给定的s_key，遍历tree node的绝对路径，且以最短匹配的规则检索；
		// 命中后返回对应的tree node，否则返回Null。
		for (char skey : key_array) {
			
			int key = skey & 0xf;
			
			TreeNode t_treeNode = treeNode.getChildTreeNode(key);
			if (t_treeNode == null) {
				
				// 该节点尚未创建：
				return null;
			}else if (t_treeNode.getValue() != null) {
				
				// 命中：
				return t_treeNode;
			}else{
				
				// 否则，将遍历下一个节点：
				treeNode = t_treeNode;
			}
			
		}
		
		// 循环体之外，将视为未命中：
		return null;
		
	}
	
	
	/**
	 * 将指定的s_key放入节点，并设置对应的value
	 * @param s_key
	 * @param value
	 * @throws Exception 
	 */
	public void insert(String s_key, Object value) throws Exception{
		TreeNode treeNode = getRoot();
		
		char[] key_array = s_key.toCharArray();
		int s_key_length = key_array.length;
		int s_key_count = 1;
		/*
		 * 根据给定的key_array的长度，查找节点、布置节点并得到最后一个节点的tree node，然后赋值value。
		 */
		for (char skey : key_array) {
			
			int key = skey & 0xf;
			
			// 取某节点下，N个子节点中的一个分支：
			TreeNode t_treeNode = treeNode.getChildTreeNode(key);
			
			if (t_treeNode == null) {
				
				// 创建一个新的子节点：
				t_treeNode = treeNode.setChildTreeNode(key);
			}else{
				
				if (t_treeNode.getValue() != null && s_key_count != s_key_length) {
					
					treeNode = null;
					break;
				}
				
			}
			
			// 该节点已经存在，节点交换：
			treeNode = t_treeNode;
			
			s_key_count++;
		}
		
		if (treeNode != null) {
			
			// 为最后一个节点赋值：
			treeNode.setValue(value);
		}
		
		
	}
	
	
	/**
	 * 删除指定key的节点
	 * @param s_key
	 * @throws Exception
	 */
	public void delete(String s_key) throws Exception
	{
		TreeNode node = search(s_key);
		if (node == null) {
			throw new Exception("Tree node not found, Tree node key is:["+s_key+"]");
		}
		
		node.removeValue();
		node = null;
		
	}
	
	
	
	
	public TreeNode getRoot() {
		return root;
	}
	
	
}

Test:

public static void main(String[] args) 
    {
    	try {
	    	BinaryTree bt = new BinaryTree();

	    	String key = "223";
	    	String msg = "hello jason";
	    	bt.insert(key, msg);
	    	
	    	TreeNode node = bt.search(key);
	    	if (node != null) {
	    		System.out.println(node.getValue());
	    	}
	    	
	    	node = bt.search("223001");
	    	if (node != null) {
	    		System.out.println(node.getValue());
	    	}
	    	
	    	
	    	System.out.println("Done!");
	    	
    	} catch (Exception e) {
    		System.out.println(e.getMessage());
    		e.printStackTrace();
    	}
    }

.

本文介绍ICANN（互联网名称与数字地址分配机构）发布的两个关于域名仲裁的政策法规，想要炒域名的同学们请尽快补习一下，以免日后吃亏。

统一域名争议解决政策（UDRP）

　　（由ICANN于1999年8月24日通过，1999年10月24日批准实施）

　　说明：

　　1、本政策业已生效。有关实施时间表，可参见网址 www.icann.org/udrp/udrp-schedule.htm.

　　2、本政策已为所有由ICANN认可的、负责为以.com、 .net、.org结尾的域名提供注册服务的注册商（registrars）所采纳，亦为某些国家顶级域名（如.nu、 .tv、 .ws等）的管理者所采纳。

　　3、 本政策是域名注册商（或者某些国家顶级域名的注册机构）和其客户（域名持有人或注册人）之间的约定。因此，本政策以"我方"或"我们的"指称域名注册商，而以"你方"或"你们的"指称域名持有人。

统一域名争议解决政策

（由ICANN于1999年10月24日批准实施）

　　1、目的：

　　本统一域名争议解决政策（"政策"）已经由互联网络名称和数码分配公司（ICANN）所采纳，并以附件的形式并入你方的注册协议。该政策为你方与我方（域名注册商）以外的任何其他方之间因你方所注册的互联网络域名的注册及使用而引发的有关争议设定了条款和条件。本政策第4条所规定的解决程序将根据《统一域名争议解决政策之规则》（《程序规则》）（该《程序规则》可见诸于网址 www.icann.org/udrp/udrp-rules-24oct99.htm）和选定的行政争议解决服务提供者的《补充规则》而进行。

　　2、你方的陈述责任：

　　你方申请注册某一域名或要求我方保留或更新某一域名注册时，即向我们陈述并保证：（a）你方注册协议中所作的陈述是完整的和准确的；（b）就你方所知，域名的注册将不会侵害或妨碍任一第三方的权益；（c）该域名的注册并非出于某种不法目的；以及（d）你方不会在明知违反有关可适用的法律或法规的情况下使用该域名。你方有责任判断你方域名注册行为是否侵害或妨碍他人权益。

　　3、撤销、转让和变更：

　　在下列情况下，我方将撤销、转让和变更域名注册：

　　（a）根据本《政策》第8条的规定，我方收到你方或你方授权代理人提交的书面的或适当电子形式的通知，要求采取此类行动；

　　（b）我方收到有管辖权的法庭或仲裁机构作出的裁定，指令采取此类行动；

　　（c） 我方收到行政专家组在依据本《政策》或依据为ICANN所采纳的本《政策》以后版本而进行的、以你方为一方当事人的任何行政程序中所作出的裁决，要求采取此类行动。（见以下第4（9）条和第4（11）条）

　　我方也可根据域名注册协议的条款或其他合法要求撤销、转让和变更域名注册。

　　4、强制性行政程序

　　本条限定了你方应交由强制性行政程序解决的争议类型。该程序将由网址 www.icann.org/udrp/approved-providers.htm 中所列明的行政争议解决服务提供者（所列明的均为行政争议解决服务提供者，以下简称"争议解决机构"）之一进行。

　　a. 适可的争议 一旦第三方（投诉人）根据《程序规则》，向一适格的争议解决机构提出如下主张时，你方有义务加入该强制性的行政程序：

　　（i） 你方域名与投诉人享有权利的商品商标或服务商标相同或混淆性相似；且

　　（ii） 你方对该域名并不享有权利或合法利益；且

　　（iii） 你方对该域名的注册和使用具有恶意。

　　投诉人在行政程序中必须举证证明以上三种情形同时具备。

　　b. 恶意注册和使用域名的证据 针对第4（a）（iii） 条，尤其是如下情形但并不限于如下情形，如经专家组发现确实存在，则构成恶意注册和使用域名的证据：

　　（i） 该情形表明，你方注册或获取域名的主要目的是为了向作为商品商标或服务商标所有人的投诉人或其竞争对手出售、出租或转让域名，以获取直接与域名注册相关费用之外的额外收益者；或者，

　　（ii） 你方注册行为本身即表明，你方注册该域名的目的是为了阻止商品商标和服务商标的所有人以相应的域名反映其上述商标者；或者，

　　（iii） 你方注册域名的主要目的是为了破坏竞争对手的正常业务者；或者，

　　（iv） 以使用域名的手段，为商业利益目的，你方通过制造你方网站或网址上所出售的商品或提供的服务与投诉人商标之间在来源者、赞助者、附属者或保证者方面的混淆，故意引诱网络用户访问你方网站或其他连机地址者。

　　c. 如何在答辩中证明你方对域名拥有权利及合法利益 你方在收到投诉书后，应根据《程序规则》第5条的规定来决定你方应如何准备答辩。针对第4（a）（ii） 条，尤其是如下情形但并不限于如下情形，如由专家组在对所提交的证据进行全面认定基础上得以证实，则表明你方对该域名拥有权利或合法利益：

　　（i） 在接到有关争议通知之前，你方在提供商品或服务的过程中已善意地使用或可证明准备善意地使用该域名或与该域名相对应的名称者；或者，

　　（ii） 你方（作为个人、商业公司或其他组织）虽未获得商品商标或有关服务商标，但因所持有的域名业已广为人知者；或者

　　（iii） 你方正非商业性地合法使用或合理地使用该域名，不存有为获取商业利益而误导消费者或玷污争议商品商标或服务商标之意图者。

　　d.争议解决机构的选择 投诉人应从业经ICANN认可的争议解决机构中选择一争议解决机构，并向该争议解决机构提交投诉书。除第4（f）条所规定的合并审理的情形外，该争议解决机构将管理案件程序性事项。

　　e. 程序的启动和行政专家组的指定 有关案件的启动程序、案件进行程序及裁决争议的专家组（"行政专家组"）的指定程序由《程序规则》另作规定。

　　f. 合并审理 如果你方与投诉人之间存有多个域名争议，你方或投诉人均可请求将这些争议交由一个行政专家组合并审理。该请求应向最初被指定负责双方间在审争议的行政专家组提出。该专家组有权决定将此类争议部分或全部予以合并审理，只要这些合并审理的争议受本《政策》或为ICANN采纳的本《政策》以后的版本所约束。

　　g. 费用 争议解决机构根据本《政策》就提交专家组解决的争议而收取的所有费用均由投诉人承担，但你方根据《程序规则》第5（b）（iv） 条的规定选择将行政专家组成员由一名专家扩充为三名专家的情形除外。在这种情形下，全部费用由你方和投诉人平均分担。

　　h. 我方在行政程序中的介入 我方不参与管理由行政专家组所进行的任何程序。此外，我方对因专家组裁决而产生的结果不承担责任。

　　i. 救济措施 投诉人通过行政专家组程序可获得的救济措施应限于要求注销你方域名或将你方注册域名转移给投诉人。

　　j. 通知和公布 争议解决机构应通知我方由行政专家组针对你方注册的域名所作出的任何裁决。所有根据本《政策》所作裁决均全文在互联网上予以公布，但专家组在特殊情形下决定裁决中不宜公布的部分除外。

　　k. 司法程序的可行性 第4条规定所要求的强制性行政程序并不排除你方或投诉人在该强制性行政程序开始之前或结束之后将争议提交有管辖权的法院独立解决。如果行政专家组裁定你方域名应予注销或转移，我们将在得到有关争议解决机构行政专家组的裁决通知后、在执行该裁决之前，等待十（10）个工作日（以我方主营业机构所在地时间为准）。然后，我们将执行裁决，除非我们在该十（10）个工作日的等待期内收到你方在投诉人根据《程序规则》第3（b）（xiii） 条提出投诉的地域针对投诉人提起司法诉讼的正式文件（如盖有法院职员归档印鉴的的起诉书副本）。（一般情况下，该地域是我们主营业机构所在地或者我方Whois数据库所记载的你方地址所在地。详细信息参见《程序规则》的第1条和第3（b）（xiii） 条）。如果我们在十（10）个工作日期间内收到了上述文件，直至我们收到（i）令我们确信双方已解决争议的证据；（ii）令我们确信你方诉讼请求已被驳回或撤销的证据；或者，（iii）法院有关驳回你方诉讼请求或裁定你方无权继续使用域名的裁定副本，我们将不执行行政专家组的裁决，也不采取进一步的进行。

　　5、 其他争议及诉讼 所有你方与除我方之外的他方当事人之间的其他并非根据本《政策》第4条强制性行政程序规定而提起的有关你方因域名注册而引起的争议，均由你方与该方当事人通过法院诉讼、仲裁和其他可适用的程序予以解决。

　　6、 我方有关争议的介入 我方不以任何方式参加你方与除我方之外的他方之间因你方注册及使用域名而产生的任何争议。你方不得在任何此类程序中将我方列为当事人之一方或以其他方式使我方介入该程序。一旦我方在此类程序中被列为当事人之一方，我们则保留进行适当辩护以及采取其他必要行动以维护我方利益的权利。

　　7、 维持现有状态 除前述第3条所规定的情形外，我方将不对根据本《政策》注册的域名予以撤销、转让、使之生效或失效，或以其他任何措施改变域名现有状态。

　　8、争议期间的转让

　　a. 将域名转让给新持有人 你方不得在下列期间将注册域名转让给另一持有人：（i）在根据第4条而提起的行政程序进行期间，或该程序终结后15个工作日内（以我方主营业机构所在地时间为准）；或者（ii）在针对你方域名注册而提起的法院诉讼程序或仲裁程序进行期间，除非接受域名转让的一方当事人书面同意接受法院判决或仲裁裁决的约束。我方保留对违反该条款规定所进行的域名转让予以注销权利。

　　b. 变更注册商 你方在根据第4条而提起的行政程序进行期间或该程序终结后15个工作日内（以我方主营业机构所在地时间为准）不得将注册域名转移给另一注册商。只要你方在我处注册的域名能够继续成为在依据本《政策》条款针对你方而提起的程序中的争议标的，你方可在法院诉讼或仲裁程序进行期间将注册域名转移给另一注册商管理。如果你方在法院诉讼或仲裁程序进行期间将域名转移给我们管理，则有关该域名的争议仍应适用原注册商的域名争议解决政策。

　　9、本政策的修订 我们有权在征得ICANN的同意后适时对本《政策》予以修订。我们将至少在修改后的政策生效前30日将其在上予以公布。如果本《政策》已为投诉人在向争议解决机构提交的投诉书中所援引，则你方应受投诉人援引时有效的政策文本约束。除此之外，无论是域名争议产生在修订文本生效之前、生效之时抑或生效之后，所有的这些修改之处均对你方具有约束力。如果你方对本《政策》的修改之处不予接受，你方唯一的救济方式是取消在我处的域名注册，但你方无权要求返还你方业已向我方支付的任何费用。业经修订的政策文本直至你方注销域名注册时为止对你方均予适用。

　　[ 2000年7月24日 ]

统一域名争议解决政策之规则

（由ICANN于1999年10月24日通过）

　　根据由ICANN采纳的《统一域名争议解决政策》而进行的争议解决行政程序受本《规则》及管理案件程序的争议解决机构通过其网站发布的《补充规则》所约束。

　　1、定义

　　在本《规则》中：

　　投诉人指就有关域名注册提起投诉的一方当事人。

　　ICANN指互联网络名称及数码分配公司。

　　交互管辖法域指，（a）注册商主营业机构所在地的法院管辖（只要域名持有人在其注册协议中已规定将有关因域名的使用而 产生的争议交付该法域法院司法管辖）或，（b）投诉提交争议解决机构之时注册商Whois数据库中域名注册信息所显示的域名持有人的地址所在地的法院管辖。

　　专家组指由争议解决机构指定的审理有关域名注册投诉的行政专家组。

　　专家指由争议解决机构指定的作为专家组成员的专家。

　　当事人指投诉人或被投诉人。

　　《政策》指《统一域名争议解决政策》。该《政策》通过援引而被并入并成为注册协议的一部分。

　　争议解决机构指由ICANN所确认的争议解决服务提供者。机构名单可查阅网址www.icann.org/udrp/approved-providers.htm.

　　注册商指为被投诉人提供争议域名注册服务的公司。

　　注册协议指注册商与域名持有人间所签订的域名注册协议。

　　被投诉人指针对其据以提起投诉的注册域名持有人。

　　反向域名侵夺指恶意地利用《政策》中的有关规定以企图剥夺注册域名持有人持有域名的行为。

　　《补充规则》指有权管理案件程序的争议解决机构制定的本《规则》之补充规则。

　　2、送达

　　（a） 在向被投诉人送达投诉书时，争议解决机构有责任采取合理可行的措施，确保被投诉人实际收到投诉书。实际收到投诉书，或争议解决机构为使被投诉人实际收到投诉书而实施以下行为后，该项责任即行解除：

　　（i）按（A）注册商Whois数据库域名注册资料中记载的注册域名持有人及其技术联系人、管理联系人以及，（B）注册商向争议解决机构提供的域名注册缴费联系人的所有邮政通讯及传真地址，将投诉书发送被投诉人的；及

　　（ii）、通过电子邮件向以下地址传送电子形式投诉书（包括可按照电子形式传送的附件）的：

　　（A）域名注册技术联系人、管理联系人及缴费联系人的电子邮件地址；

　　（B）postmaster＠<争议域名>；及

　　（C）如果域名（或www.后紧接该域名）解析至一个有效网页（该网页并非争议解决机构所确认的由注册商或ISP所预留的、可搁置由多个域名持有人所注册的域名的一般性网页）时，该网页所显示的任何电子邮件地址或该网页所能链接的任何电子邮件地址；

　　（iii）按照被投诉人自行选择并通知争议解决机构的任何地址，及在可行的范围内向由投诉人根据第3（b）（v） 条向争议解决机构提供的所有其他地址发送投诉书的。

　　（b） 除第2 （a） 条规定的情形外，依本《规则》向投诉人和被投诉人传送的任何书面文件均应分别根据投诉人和被投诉人选定的方式为之（见第3 （b） （iii）条和第5 （b） （iii）条），或在没有这种指示时

　　（i）通过带有传输确认的传真方式传送；或

　　（ii）预付邮资并通过带有收据的邮寄或快递方式发送；或

　　（iii）在能获得传送记录的情况下，通过互联网以电子形式传送。

　　（c）向争议解决机构或专家组提交的任何文件均应按争议解决机构《补充规则》所规定的方法和方式（包括分数）提交。

　　（d）文件应以第11条所规定的语文制作。如果可行的话，电子文件应以简易文本传送。

　　（e）任何一方当事人均可通知争议解决机构和注册商，以更新其详细联络信息。

　　（f）除非本《规则》另有规定，或专家组另有决定，根据本《规则》所提交的所有文件于下列情形下应视为已经送达；

　　（i）通过传真方式传送的，以传送确认书上显示的日期为准；或

　　（ii）通过邮寄或快递方式发送的，以收据上标注的日期为准，或

　　（iii）通过互联网络传送的，在传送日期可予验证的情况下，以该文件传送日期为准。

　　（g）除非本《规则》另有规定，所有本《规则》所规定的文件提交开始的期间应当从依第2（f） 条之规定文件最早视为业已提交的日期开始计算。

　　（h）任何文件，

　　（i）凡由专家组传送给任何一方当事人者，必须同时向争议解决机构和另一方当事人传送文件副本；

　　（ii）凡由争议解决机构传送给任何一方当事人者，必须同时向另一方当事人传送文件副本；以及

　　（iii）凡由一方当事人提交者，必须同时向另一方当事人、专家组以及争议解决机构传送文件副本。

　　（i）文件传送方有义务为其传送的文件保留记录，以记载有关文件传送的具体事实和情况，供有关当事方查阅，并用以制作相应的报告。

　　（j）如果传送文件的一方当事人收到告知未收到其所传送文件的通知，该当事人应立即将有关情况通知专家组（或者，如果专家组尚未指定，通知争议解决机构）。有关文件传送和回复的进一步程序均应依照专家组（或争议机构）的指示而为之。

　　3、投诉

　　（a）任何个人或企业均可依据《政策》及本《规则》向经ICANN认可的争议解决机构提出投诉以启动行政程序。（由于资质限制或其他原因，争议解决机构受理投诉的资格可能会暂时中止。在这种情况下，争议解决机构应拒绝受理投诉。有关个人或企业可向另一争议解决机构提请投诉。）

　　（b）投诉书应以有形书面文件形式及电子文件形式（无法获得电子格式的附件除外）提交，并且应当：

　　（i）载有有关投诉应根据《政策》和本《规则》予以裁决的请求；

　　（ii）提供投诉人及其行政程序授权代表的姓名、通讯及电子邮件地址以及电话和传真号码；

　　（iii）确定在行政程序中就（A）电子文件材料和（B）包含有形书面文件的材料与投诉人联络的首选通讯方式（包括联系人、联系方式及联络地址）；

　　（iv）决定投诉人是选择一人专家组裁决纠纷，还是三人专家组裁决纠纷。如果投诉人选择由三人专家组裁决纠纷，则应提供将会被指定作为案件专家组成员之一的三位候选专家的姓名和详细的联络信息（三位候选专家可从任何一个业经ICANN确认的争议解决机构的专家名单中选定）；

　　（v）提供被投诉人（域名持有人）的名称及为投诉人所知的如何联络被投诉人及其代表的包括投诉前双方协商过程中的联络信息在内的所有信息（包括所有的通讯及电子邮件地址以及电话和传真号码），上述信息应详细具体足以允许争议解决机构将投诉书按第2（a）条所述方式发送被投诉人；

　　（vi）明确作为投诉标的的域名；

　　（vii）确定投诉提起之时注册域名的注册商；

　　（viii）明确据以提出投诉的商品商标或服务商标。就每一商标而言，如果有的话，则应说明据以使用商标的商品或服务（投诉人亦可分别说明在投诉提起之时被投诉人意欲将来使用该商标的商品及服务）；

　　（ix）根据《政策》规定，说明据以提起投诉的理由，尤其应包括：

　　（1）争议域名与投诉人享有权利的商品商标或服务商标相同或混淆性相似；及

　　（2）被投诉人（域名持有人）对争议域名不享有权利或不具备合法利益的原因；及

　　（3）争议域名被认为系属恶意注册和使用的理由。

　　（就第（2）项和第（3）项而言，投诉人应讨论应予适用的《政策》第4（b）条和第4（c）条所规定的各个方面。有关说明的字数应符合争议解决机构《补充规则》有关字数或文件页数的限制。）；

　　（x）根据《政策》规定，明确所寻求的补救方式；

　　（xi）说明任何其他已经开始或业已终止的与争议域名相关的司法程序；

　　（xii）声明已经根据第2（b）条的规定，连同争议解决机构《补充规则》所规定的格式封面，向被投诉人（域名持有人）发送或传送了投诉书副本；

　　（xiii）声明投诉人如对行政程序关于取消或转移域名的裁决有任何异议，将把有关争议提交至少一个确定的交互管辖法域的法院予以管辖；

　　（xiv）投诉书的结尾应附有下列声明，并由投诉人或其授权代表签署：

　　"投诉人同意，其有关域名注册、争议或争议解决的投诉及救济主张仅针对域名持有人，该投诉及救济主张不涉及（a）争议解决机构及专家，但故意不当行为除外，（b）注册商，（c）注册官员，及（d）互联网络名称和数码分配公司，以及上述机构的董事、官员、雇员及代理商。"

　　"投诉人确认，投诉书所载信息就其所知是完整的和准确的。本投诉并非出于诸如讹诈等任何不正当目的。投诉人保证投诉书有关主张是依据本《规则》和应予适用的法律而提出，犹如其现存状态或可由善意及合理抗辩而展延之状态。"

　　（xv）包括争议域名应予适用的《政策》副本及投诉赖以依存的注册商标和服务商标在内的任何文件或其他证据应作为附件提交，并应同时提供上述证据的目录索引表；

　　（c）投诉人可对多个域名提出投诉，只要这些域名为同一域名持有人所注册。

　　4、投诉通知

　　（a）争议解决机构应对投诉书予以行政审查。如果投诉书符合《政策》及本《规则》规定，争议解决机构将在收到投诉人根据第19条交纳的费用后3个历日内依第2（a）条所规定的方式将投诉书（连同争议解决机构《补充规则》所规定的说明性格式封面）送达被投诉人。

　　（b）如果争议解决机构发现投诉书存有形式缺陷，则应立即将该缺陷通知投诉人和被投诉人。投诉人应在收到通知后5个历日内对该缺陷予以修改。投诉人未能在上述期限内对投诉书形式缺陷予以修改者，行政程序将视为撤回，但并不妨碍投诉人提出另一不同的投诉。

　　（c）争议解决机构依第2（a）条完成向被投诉人送达投诉文件职责之日即为行政程序开始之日。

　　（d）争议解决机构应立即将行政程序开始日期通知投诉人、被投诉人、有关注册商及ICANN.

　　5、答辩

　　（a）被投诉人应在行政程序开始之日起20日内向争议解决机构提交答辩。

　　（b）答辩应以有形书面文件和电子文件（没有电子格式的附件除外）形式提交，并应当：

　　（i）对投诉书中的陈述和主张予以具体反驳，并申明被投诉人（域名持有人）保留域名注册和继续使用争议域名的所有依据和具体理由（答辩书该部分字数应当符合争议解决机构《补充规则》所规定的字数或页数限制）；

　　（ii）提供被投诉人（域名持有人）及其授权行政程序代理人的姓名、通讯及电子邮件地址以及电话和传真号码；

　　（iii）确定在行政程序中就（A）电子文件材料和（B）包含有形书面文件的材料与被投诉人联络的首选通讯方式（包括联系人、联系方式及联络地址）；

　　（iv）如果投诉人在投诉书中选择一人专家组审理案件（见第3（b）（iv）条），则应声明被投诉人是否选择将争议交由三人专家组裁决；

　　（v）如果投诉人抑或被投诉人选择了三人专家组，则应提供将会被指定作为案件专家组成员之一的三位候选专家的姓名和详细的联络信息（这些候选专家可从任一经ICANN确认的争议解决机构专家名单中选定）；

　　（vi）明确与争议域名有关的已经开始或业已终止的任何其他司法程序；

　　（vii）声明已经依照第2（b）条之规定向投诉人发送或传送了答辩书副本；

　　（viii）答辩书的结尾应附有下列声明，并经被投诉人或其授权代表签署：

　　"被投诉人确认，答辩书中所含信息就其所知是完整的和准确的。该答辩并非出于诸如讹诈等任何不正当目的。被投诉人保证答辩书有关主张是依据本《规则》和应予适用的法律而提出，犹如其现存状态或可由善意及合理抗辩而展延之状态。"

　　（ix）任何答辩赖以依存的文件或其他证据应作为附件提交，并应同时提供上述证据的目录索引表。

　　（c）如果投诉人选择将争议交由一人专家组裁决，而被投诉人选择将争议交由三人专家组裁决，被投诉人则应承担争议解决机构《补充规则》所规定的三人专家组费用的一半。该费用应在向争议解决机构提交答辩时一并交付。如所应收取的费用未能应要求交付，争议将由一人专家组审理。

　　（d）应被投诉人请求，争议解决机构可在个别案件中延长提交答辩的期限。该期限亦可因当事人之书面约定而展延，只要该约定获经争议解决机构批准。

　　（e）如果被投诉人未提交答辩，如无特殊情形，专家组应依据投诉书裁决争议。

　　6、专家组的指定及裁决期限

　　（a）每个争议解决机构应制定并公布包括专家姓名及其适格性在内的专家名册。

　　（b）如果投诉人和被投诉人均未选择三人专家组（第3（b）（iv）条和第5（b）（iv）条），争议解决机构将在收到被投诉人答辩或答辩期限届满后5日内从其专家名册中指定一名独任专家。一人专家组费用应全部由投诉人承担。

　　（c）如果投诉人或被投诉人之一方选择将争议交由三人专家组裁决，争议解决机构应根据第6（e） 条所规定的程序指定三位专家。三人专家组费用应全部由投诉人承担，但三人专家组由被投诉人选择者除外。在后一种情形下，所涉费用应由双方各半分担。

　　（d）除非投诉人已经选择三人专家组，投诉人应在收到有关被投诉人选择三人专家组的答辩书后5个历日内，向争议解决机构提交将被指定作为案件专家组成员之一的三位候选专家的姓名和详细联络信息。这些候选专家可从经ICANN认可的任一争议解决机构的专家名单中选定。

　　（e）如果投诉人或被投诉人之一方选择三人专家组，争议解决机构应尽量从投诉人及被投诉人提供的候选专家名单中各自指定一名专家。如果争议解决机构未能在5个历日内按其惯常条件从双方候选专家名单中各自指定一名专家，则争议解决机构将从其专家名册中予以指定。第三名专家应由争议解决机构从其提供给当事人的五位候选专家名单中指定。争议解决机构在指定第三名专家时，应尊重当事人双方在争议解决机构向其提交五位候选专家名单后5个历日内所可能作出的选择，合理地平衡双方当事人的意愿，。

　　（f）专家组一经指定，争议解决机构应将指定的专家及如无特殊情况专家组应将有关投诉的裁决提交争议解决机构的日期通知双方当事人。

　　7、独立与公正

　　专家应独立公正，并应在接受指定前向争议解决机构披露对其独立公正产生合理怀疑的任何情形。如果在行政程序进行过程中的任何阶段出现了可导致对其独立公正产生合理怀疑的新情况，则该专家应立即将该情形向争议解决机构予以披露。在这种情况下，争议解决机构有权指定替代专家。

　　8、当事人与专家组之间的联络

　　任何一方当事人或其代理人均不得与专家组进行单方联络。当事人一方与专家组或争议解决机构间的所有联络均应通过争议解决机构根据其《补充规则》之规定方式指定的案件经办人进行。

　　9、案件移交专家组

　　当专家组由一人组成时，该专家一经指定，或当专家组由三人组成时，最后一位专家一经指定，争议解决机构即应将案件移交专家组。

　　10、专家组一般性权利

　　（a）专家组应以其根据《政策》和本《规则》而认为适当的方式进行行政程序。

　　（b）在所有案件中，专家组应确保平等地对待双方当事人，并保证每一方当事人均拥有平等的机会陈述案情。

　　（c）专家组应确保行政程序快速进行。专家组可应一方当事人请求或自行决定在特殊情形下延长本《规则》或专家组所确定的时限。

　　（d）专家组有权决定证据的可接受性、关联性、实质性和重要性。

　　（e）专家组可根据《政策》和本《规则》规定应一方当事人的请求决定对多个域名争议合并审理。

　　11、程序所使用的语文

　　（a）除非当事人另有约定或注册协议另有规定，以及专家组根据行政解决程序的具体情形另有决定，行政程序所使用的语文应是注册协议所使用的语文。

　　（b）专家组可裁定要求当事人提交的任何非以行政程序所应使用的语文制作的文件均应全部或部分地附具行政程序所应使用语言的译文。

　　12、进一步陈述

　　除投诉书和答辩书外，专家组可自行决定要求当事人一方就所涉案件提供进一步的陈述或提交相关文件。

　　13、当庭听证

　　除非专家组在特殊情形下自行决定，当庭听证对裁决争议确有必要，正常情况下不举行当庭听证（包括以电话会议、视频会议及网络会议所进行的任何听证）。

　　14、缺席

　　（a）当事人一方，如无特殊情形，不遵守本《规则》或专家组所确定的任何时限，专家组将继续进行行政程序，直至就所涉投诉作出裁决。

　　（b）当事人一方，如无特殊情形，不遵守本《规则》之规定或要求或专家组的任何指令，专家组应以其认为适当的情形对此予以推论。

　　15、专家组裁决

　　（a）专家组应基于当事人所提交的陈述及证据，根据《政策》、本《规则》以及可予使用的法律规则和原则裁决争议。

　　（b）如无特殊情形，专家组应在根据第6条被指定后14日内将有关投诉之裁决提交争议解决机构。

　　（c）如果是三人专家组，裁决应以多数意见作出。

　　（d）专家组裁决应为书面，说明裁决理由，注明裁决作出日期，并写明专家姓名。

　　（e）专家组裁决及有关不同意见通常应符合争议解决机构《补充规则》关于文件长度的要求。任何不同意见均应载入以多数意见所作之裁决。如果专家组认为所涉争议不属于《政策》第4（a） 条所规定之范围，则应予以说明。如果专家组经审阅当事人所提交之文件后认定投诉具有恶意，例如属于反向域名侵夺之情形或其本意在于讹诈域名持有人，专家组应在裁决中宣布，投诉具有恶意并构成对行政程序的滥用。

　　16、裁决送达当事人

　　（a）争议解决机构应在收到专家组提交的裁决后3个历日内将裁决书全文发送各方当事人、有关注册商及ICANN.有关注册商应立即将根据《政策》之规定执行裁决的日期告知各方当事人、争议解决机构和ICANN.

　　（b）除专家组另有决定外（见《政策》第4（j）条），争议解决机构应将裁决全文及其执行日期在一公开网站上予以公布。无论何种情形，裁决中有关投诉构成恶意的部分均应予以公开。

　　17、和解或其他终止程序的事理

　　（a）如果在专家组作出裁决之前，当事人达成和解，专家组应终止行政程序。

　　（b）如果在专家组作出裁决之前，因其他原因行政程序已无必要继续进行或不可能继续进行，专家组应决定终止行政程序，除非一方当事人在专家组规定的时间内提出合理的反对理由。

　　18、司法程序的效力

　　（a）如果在行政程序开始之前或进行的过程中已就争议域名提起了司法程序，专家组有权自行决定中止或终止行政程序，或继续行政程序，直至作出裁决。

　　（b）如果一方当事人在行政程序进行期间就争议域名提起了司法程序，其应立即通知专家组和争议解决机构。见上述第8条。

　　19、费用

　　（a）投诉人应根据争议解决机构《补充规则》之规定，按规定的时间和金额，向争议解决机构支付固定的基本费用。如果被投诉人根据第5（b）（iv）条之规定选择将争议交由三人专家组裁决，而不是交由投诉人选择的一人专家组裁决，则三人专家组费用的一半应由被投诉人承担，并由其向争议解决机构支付（见第5（c）条）。在其他情形下，争议解决机构所有费用应由投诉人承担，但第19（d）条规定的情形除外。专家组一经指定，争议解决机构应根据争议解决机构《补充规则》的规定，将适当比例的基本费用，如果有的话，返还给投诉人。

　　（b）在投诉人未根据第19（a）条之规定向争议解决机构缴纳基本费用前，争议解决机构不应就有关投诉采取行动。

　　（c）如果争议解决机构在收到投诉后10个历日内未收到有关费用，视投诉视为撤回，行政程序予以终止。

　　（d）在特殊情形下，例如举行当庭听证，争议解决机构应要求当事人双方另外付费。该费用应经协商当事人双方和专家组后确定。

　　20、责任排除

　　除故意不当行为外，争议解决机构抑或专家均不就与根据本《规则》而进行之行政程序有关的任何行为或疏忽向一方当事人承担责任。

　　21、修改

　　有关行政程序适用向争议解决机构提交投诉之时有效的本《规则》之文本。本《规则》只有在得到ICANN明示书面确认后方可予以修订。

　　（原文见：http://www.icann.org/udrp/udrp-rules-24oct99.htm）

　　[ 2000年7月24日 ]

创建型模式

1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory

工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句 话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻 松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）

建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你要不要）

原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。

5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事)

单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。

结构型模式

6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)

适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

7、BRIDGE —早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了

桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。

8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商店，你自己 挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好 配成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有？

合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。

9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费肯定玩 完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞 美术设计的Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀，怎么样，看懂了吗？

装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。

10、FACADE —我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个相机给我拍张照片了。

门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。

11、FLYWEIGHT —每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，根据上下文情况使用。

享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元 模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态不能影 响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享 的对象，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的数量。

12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。

代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构 代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。客户端分辨不出 代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对象 必须有系统的其他角色代为创建并传入。

行为模式

13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说是个老处女呀，快跑!

责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接

起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户 端的情况下动态的重新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我 有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三 个男朋友送COMMAND，就数你最小气，才请我吃面。”，:-(

命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委 派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否 执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。

15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执行就可以了。

解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这 个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对 象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令对 象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。

16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。

Mary：“想要我跟你结婚，得答应我的条件”

我：“什么条件我都答应，你说吧”

Mary：“我看上了那个一克拉的钻石”

我：“我买，我买，还有吗？”

Mary：“我看上了湖边的那栋别墅”

我：“我买，我买，还有吗？”

Mary：“你的小弟弟必须要有50cm长”

我脑袋嗡的一声，坐在椅子上，一咬牙：“我剪，我剪，还有吗？”

……

迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称 之为聚集，聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了聚集的界面。每 一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。

17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺得到了四个MM的电话。

调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用。从而使他们可以松散偶 合。当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对 多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理。

18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存，这样可以随时察看以前的记录啦。

备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦

观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，比如你约她今天晚上 去看电影，对你没兴趣的MM就会说“有事情啦”，对你不讨厌但还没喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点 钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状态从不讨厌不喜欢变成喜欢哦。

状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模 式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其 行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。

21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中有好多Strategy哦。

策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策 略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中提供。由于算法 和环境独立开来，算法的增减，修改都不会影响到环境和客户端。

22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随机应变啦(具体实现)；

模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而将逻辑的细节留给具体的子类去实现。

23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要针对她个人的特 点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品 店老板也根据每个人特点选一张卡，这样就轻松多了；

访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这 个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由 的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类 中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构 的成员类。