(零雨其蒙原创 转载请注明)
2007
						
				
				
						年
						
								3
						
				
				
						月
						
								13
						
				
				
						日星期二
						
								
								
								
						
				
		
		
				第
				
						35
				
				章
				
				
				包的设计
		
		
				
						包设计的核心就是提供稳定的包设计,减少依赖造成的影响!
						
								
								
						
				
		
		
				组织包结构的准则
		
		
				
						
								
										   
								
						
						
								准则
								
										
										
								
						
				
				
						
								
										
												    
										
								
						
						
								包在水平和垂直划分上的功能性内聚。
						
						最基本的“直观性”原则是基于功能性内聚的模块,将参与共同目的、服务、协作、策略和功能的强相关类型(类或接口)组织在一起。除此之外,还可以根据类型之间的偶合程度进行分组。
				
		 
		
				
						
								 
						
				
		
		
				
						
								 
						
				
		
		
				
						
								
										   
								
						
						
								准则
								
										
										
								
						
				
				
						
								
										    
								
						
						
								由一族接口组成的包。
						
						将一组功能上相关的接口放入单独的包,与其实现类分离。
				
		 
		
				
						
								 
						
				
		
		
				
						
								
										   
								
						
						
								准则
								
										
										
								
						
				
				
						
								
										    
								
						
						
								用于正式工作的包和用于聚集不稳定类的包。
						
						以包来发布产品,则将包内稳定的部分分成一个包(正式工作的包),包内需要经常修改和重新发布的部分分成一个包(用于聚集不稳定类的包)。基本策略:减少对不稳定包的广泛依赖。
						
								
										
										
								
						
				
		 
		
				
						
								 
						
				
		
		
				
						
								
										  
										 
								
						
						
								准则
								
										
										
								
						
				
				
						
								
										
												    
										
								
						
						
								职责越多的包越需要稳定。
						
						职责多就意味着有许多包要依赖于此包,如果其不稳定,就会殃及许多依赖于它的包。
				
		 
		
				
						
								 
						
				
		
		
		
				
						
								 
						
				
		
		
				
						
								准则
								
										
										
								
						
				
				
						
								
										
												  
										
								
						
						
								使用工厂模式减少对具体包的依赖。
						
						减少对其他包中具体类的依赖是提高包的稳定性的一个途径。
				
		 
		
				
						
								 
						
				
		
		
				
						
								准则
								
										
										
								
						
				
				
						
								
										
												   
										
								
						
						
								包之间没有循环依赖。
						
						解决循环依赖有两个方案,一个是将参与循环的类型(类或接口)分解出来形成较小的新包;另一个是使用接口来打破循环,具体做法就是在一个新包中定义一个新的接口,使原来循环依赖的两个类一个实现新的接口,一个依赖新的接口,
				
		 
		
				
						
								 
						
				
		
		
				增强包的稳定性的方法
		
		
				
						l         
				
				包中仅包含或者主要包含接口和抽象类
		
		
				
						l         
				
				不依赖于其他的包(这种包是独立的),或者仅依赖非常稳定的包,或者封装了依赖关系以使其不受影响(比如将特定的实现细节隐藏在一个
				
						façade
				
				对象之后,其他对象只对
				
						façade
				
				对象产生依赖,这就是封装依赖关系的一种方式。)。
		
		
				
						l         
				
				包含相对稳定的代码,这些代码在发布之前经过充分的测试和精化。
		
		
				
						l         
				
				强制规定具有缓慢的变化周期。
		
		
				
						
								 
						
				
		
		
				
						
								 
						
				
		
		
				第
				
						36
				
				章
				
				
				使用
				
						GoF
				
				模式完成更多对象的设计
		
		
				关于异常和错误处理
		
		
				
						
								
										
												    
										
								
						
						
								在
								
										UML
								
						
						
								中,异常是一个特殊的信号(
								
										Signal
								
						
						
								)(表示对象之间的异步通信)。这意味着,在交互图中,异常被表示为异步消息(
								
										P429
								
						
						
								)。
								
										
										
								
						
				
		 
		
				
						
								 
						
				
		
		
				
						
								 
						
				
		
		
				
						Proxy
				
				代理模式
		
		
				
						
								代理只不过是与被代理对象实现相同的接口,它保存指向被代理对象的引用,并且用于控制对被代理对象的访问(
								
										P431
								
						
						
								)。
								
										
										
								
						
				
		 
		
				
						
								 
						
				
		
		
				
						
								 
						
				
		
		
				
						
								问题:
						
						不希望或不可能直接访问真正的主题对象时,应该怎么办?
				
				
						
								解决方案
						
						:通过代理对象增加一层间接性,代理对象实现与主题对象相同的接口,并且负责控制和增强对主题对象的访问。
				
		 
		
				
						
								 
						
				
		
		
				
						我觉得代理对象(
						
								Proxy Object
						
						)就是一个和被代理的对象拥有相同接口的控制器,在正常情况下,它执行被代理对象的功能,如果失败或其他原因,则转向其他对象进行处理。更通俗的理解代理就像是经纪人,有什么事情经纪人会替艺人出面摆平,代替艺人回答问题,或者把问题的焦点转向别处,比如经纪公司。
				
		 
		
				
						
								 
						
				
		
		
				
						
								 
						
				
		
		
				
						Abstract Factory
				
				抽象工厂
		
		
				
						
								问题:
						
						如何创建实现相同接口的一族相关的类?
				
				
						
								解决方案
						
						:定义一个工厂接口(抽象工厂)。为每一族要创建的事物定义一个具体工厂类。也可以定义实际的抽象类来实现工厂接口,并且为扩展该抽象类的具体工厂提供公共服务。
				
		 
		
				
						
								 
						
				
		
		
				刚开始看这个话觉得真是让人费解,什么叫一族相关的类啊?看了例子隐约明白了,一族就是一堆,只不过这一堆有相似之处,就像是一个家族或种族的人一样,比如
				
						IBMJavaPOSDevicesFactory
				
				和
				
						NCRJavaPOSDevicesFactory
				
				,它们是不同供应商提供的
				
						POS
				
				设备
				
						Java
				
				驱动程序。一个家族的人往往从事一样的事(或许远古时代是这样,比如一个狩猎家族或食人家族),这一族类也实现相同接口(意味着它们拥有相同的公共方法)。看
				
						436
				
				页的类图就可以明白这个模式是怎么回事了。
		
		
				
						
								 
						
				
		
		
				
						
								 
						
				
		
		
				
						Do It Myself
				
				模式
		
		
				
						
								“
								
										Do It Myself
								
						
						
								”
								
										
										
								
						
				
				
						
								
										
												 
												  
												 
										
								
						
						
								我(一个软件对象)是对实际对象的抽象,由我来完成这些通常由实际对象所完成的事情。
								
										[Coad95]
								
						
				
		 
		
				
						
								 
						
				
		
		
				其实看了这个模式让我觉得很高兴,因为在此之前,我通过自己的学习实践和领悟,觉得设计对象的最基本的原则就是在现实生活中这个对象是什么样的(拥有什么属性,能干什么事),设计的软件对象就是什么样的,这是最自然的原则。我觉得很多设计方面的问题都可以用最自然的方式解决,比如说工厂模式,很自然,实际生活中的对象(鞋子,人)都是由工厂创造的(或是母亲生的);还比如说代理模式,如果你不能直接跟一个人打交道,自然就会寻找代理。
				
						Larman
				
				在这部分总是说“
				
						DIM
				
				模式和多态通常盗跖相同的设计选择”“
				
						DIM
				
				模式和信息专家模式通常导致相同的设计选择”。
				
						Larman
				
				说“这是经典的面向对象设计风格。”但他并没有说这是最自然最根本的设计风格,或许在
				
						Peter Coad
				
				的著作中出现过这样的字眼,有空再看看。不仅想到了庄子道家提倡的“大道自然”,最自然的东西就是最正确的,最合理的,最和谐的!人设计敌不过天设计(人算不如天算),现在人还不能设计出和自然界设计出来的人相媲美的机器人。