适配器模式和外观模式

适配器模式:

将一个类的接口，转换成客户指望的另外一个接口。适配器让本来不兼容的类能够合做无间。

例子:

//将Enumeration转换成Iterator
public class EnumerationIterator implements Iterator{

	Enumeration enum;

	public EnumerationIterator(Enumeration enum){
		this.enum = enum;
	}

	public boolean hasNext(){
		return enum.hasMoreElements();
	}

	public Object next(){
		return enum.nextElement();
	}

	public void remove(){
		throw new UnsupportedOperationException();
	}
}

外观模式提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用

外观模式之"最少知识"原则

设计原则:

最少知识原则：只和你的密友谈话。这个原则但愿咱们在设计中，不要让太多的类耦合在一块儿，省得修改系统中一部分，会影响到其余部分。若是许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，它须要花许多成本维护，也会由于太复杂而不容易被其余人了解。

墨忒(tui第一声)耳法则:

墨忒耳法则和最少知识原则的关系:

两个名词指的是同一个原则。咱们倾向于使用最少知识原则来称呼它是由于如下两个缘由:(1)这个名字更加直接。(2)法则(Law)给人的感受是强制的。事实上，没有任何原则是法律,全部原则都应该在有帮助的时候才遵照。搜友的设计都难免须要折衷(在抽象和速度之间取舍，在空间和时间之间平衡...)。虽然原则提供了方针，但在采用原则以前，必须全盘考虑全部的因素。

优势:

减小了对象之间的依赖，研究显示这会减小软件的维护成本。

缺点:

采用这个原则也会致使更多的"包装"类被制造出来，以处理和其余组件的沟通，这可能会致使复杂度和开发时间的增长，并下降运行时的性能。

最少知识原则例子:

//错误的:
public House{
	WeatherStation station;

	//其余的方法和构造器
	public float getTemp(){
		return station.getThermometer().getTemperature();
	}
}

//正确的:
public House{
	WeatherStation station;

	//其余的方法和构造器
	public float getTemp(){
		Thermometer thermometer = station.getThermometer();
		return getTempHelper(thermometer);
	}

	public float getTempHelper(Thermometer thermometer){
		return thermometer.getTemperature();
	}
}

要点:

• 当须要使用一个现有的类而其接口并不符合你的需求时，就使用适配器。
• 当须要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。
• 适配器改变接口以符合客户的指望。
• 外观将客户从一个复杂的子系统中解耦。
• 实现一个适配器可能须要一番功夫，也可能不费功夫，视目标接口的大小与复杂度而定。
• 实现一个外观，须要将子系统组合进外观中，而后将工做委托给子系统执行。
• 适配器模式有两种形式：对象适配器和类适配器。类适配器须要用到多重继承(在JAVA语言中不可用)
• 你能够为一个子系统实现一个以上的外观
• 适配器将一个对象包装起来以改变其接口；装饰者将一个对象包装起来以增长新的行为和责任；而外观将一群对象"包装"起来以简化其接口。