标签:cti sys 装饰者模式 避免 额外 方法 交互 基础 lan
适配器的本质是一种包装,所以可以从装饰者模式谈起。
装饰者利用继承,动态地将新的责任与功能附加到基础对象上。这在组件和基础对象拥有相同的基本接口很有效,但如果即使装饰也不能使对象满足用户所需的接口,那装饰者模式就显得无力。
适配器模式很好地解决了接口不匹配的问题。
举例来说,当希望使用A
接口却只有类似的B
对象时,需要用一个实现A
接口的类来包装B对象。
package adapter;
public interface A {
public void actionA();
}
package adapter;
public class B {
public void actionLikeA() {
System.out.println("Action");
}
}
package adapter;
public class BAdapter implements A{
B b;
public BAdapter(B b) {
this.b = b;
}
@Override
public void actionA() {
b.actionLikeA();
}
}
通过上面的包装,现在对可以利用BAdapter
类来对B
使用A
的接口了。
注意:由于使用的是接口而不是继承,适配器可以是被适配者同时适用于多个调用接口,甚至可以使双方互相适配。
除上述这种对象适配器外,也有类适配器。但由于类适配器使用了多重继承,所以在Java
中不能实现。
与适配器不同,外观模式虽然同样是包装,但目的在于简化接口。
以家庭影院为例。一个优秀的家庭影院可能包含一套十分复杂的子系统,如果要直接使用这套子系统,就需要繁琐地操作子系统中的每一个组件的各种方法。面对这种问题,可以用外观类来包装整个子系统,并对外提供一些组合功能。比如:观赏电影可能需要使用到爆米花机、灯光、屏幕、投影机等等,而对这些类的操作在外观中被包装为“观赏电影”这一个简单易懂的方法。
但外观系统并没有封装整个子系统,而仅仅额外地提供了一层简化的接口。用户可以使用外观提供的接口,也可以拒绝而选择更加“硬核”的操作方式,这种选择的权力归用户所有。
当设计一个系统时,要关注互相交互的类之间的关系。避免过多的类耦合在一起,导致牵一发而动全身的严重后果。
避免的方针在于,在一个对象的方法内,只应该调用属于以下范围的方法:
该对象本身
被当作方法的参数而传递进来的对象
此方法所创建或实例化的任何对象
对象的任何组件
标签:cti sys 装饰者模式 避免 额外 方法 交互 基础 lan
原文地址:https://www.cnblogs.com/aries99c/p/12838113.html