设计模式适配器模式与外观模式

Posted 2020-12-08 aries99c

适配器模式

适配器的本质是一种包装，所以可以从装饰者模式谈起。

装饰者模式

装饰者利用继承，动态地将新的责任与功能附加到基础对象上。这在组件和基础对象拥有相同的基本接口很有效，但如果即使装饰也不能使对象满足用户所需的接口，那装饰者模式就显得无力。

适配器模式

适配器模式很好地解决了接口不匹配的问题。

举例来说，当希望使用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中不能实现。

外观模式

与适配器不同，外观模式虽然同样是包装，但目的在于简化接口。

以家庭影院为例。一个优秀的家庭影院可能包含一套十分复杂的子系统，如果要直接使用这套子系统，就需要繁琐地操作子系统中的每一个组件的各种方法。面对这种问题，可以用外观类来包装整个子系统，并对外提供一些组合功能。比如：观赏电影可能需要使用到爆米花机、灯光、屏幕、投影机等等，而对这些类的操作在外观中被包装为“观赏电影”这一个简单易懂的方法。

但外观系统并没有封装整个子系统，而仅仅额外地提供了一层简化的接口。用户可以使用外观提供的接口，也可以拒绝而选择更加“硬核”的操作方式，这种选择的权力归用户所有。

最少知识原则：只和你的密友谈话

当设计一个系统时，要关注互相交互的类之间的关系。避免过多的类耦合在一起，导致牵一发而动全身的严重后果。

避免的方针在于，在一个对象的方法内，只应该调用属于以下范围的方法：

• 该对象本身

• 被当作方法的参数而传递进来的对象

• 此方法所创建或实例化的任何对象

• 对象的任何组件