适配器模式和外观模式

最新推荐文章于 2025-09-08 09:22:18 发布

阅读量59

点赞数

CC 4.0 BY-SA版权

文章标签： python java

原文链接：https://my.oschina.net/u/3843989/blog/2250111

本文探讨了适配器模式和外观模式在软件设计中的应用。适配器模式通过转换现有类的接口以满足客户期望，使不兼容的类能够协同工作。外观模式则通过提供统一的接口简化子系统的使用，遵循最少知识原则，减少类间的依赖，降低系统维护成本。

2019独角兽企业重金招聘Python工程师标准>>>

适配器模式:

将一个类的接口，转换成客户期望的另一个接口。适配器让原本不兼容的类可以合作无间。

例子:

//将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();
	}
}

要点: