设计模式之禅笔记6

享元模式

• 定义：使用共享对象可有效的支持大量的细粒度的对象。
  是池技术的重要实现方式。有两个要求:细粒度的对象和共享对象。
  把对象的信息分为两个部分，内部状态和外部状态。
  内部状态：指的是对象可共享出来的信息，存储在享元对象内部并且不会随环境改变而改变。
  外部状态：值得是对象得以依赖的一个标记，是随环境改变而改变的、不可共享的状态。
• 主要角色：
  
  1. FlyWeight: 抽象享元角色，定义出对象的外部状态和内部状态的接口或实现。
  2. ConcreteFlyWeight:具体享元角色，实现抽象角色定义的业务。需要注意的是内部状态处理应该与环境无关。
  3. unsharedConcreteFlyWeight:不可共享的享元角色。
  4. FlyweightFactory:享元工厂。构造一个池容器，同时提供从池中获得对象的方法。
• 通用源码：

public abstract class Flyweight {
    //内部状态
    private String intrinsic;
    //外部状态
    protected final String Extrinsic;
    //要求享元角色必须接受外部状态
    public Flyweight(String _Extrinsic){
        this.Extrinsic = _Extrinsic;
    }

    //定义业务操作
    public abstract void operate();

    //内部状态的getter/setter
    public String getIntrinsic() {
        return intrinsic;
    }
    public void setIntrinsic(String intrinsic) {
        this.intrinsic = intrinsic;
    }   

}
public class ConcreteFlyweight1 extends Flyweight{

    public ConcreteFlyweight1(String _Extrinsic){
        super(_Extrinsic);
    }

    //根据外部状态进行逻辑处理
    public void operate(){
        //业务逻辑
    }


}
public class ConcreteFlyweight2 extends Flyweight{

    public ConcreteFlyweight2(String _Extrinsic){
        super(_Extrinsic);
    }

    public void operate(){
        //
    }
}
public class FlyweightFactory {
    //定义一个池容器
    private static  HashMap<String,Flyweight> pool= new HashMap<String,Flyweight>();

    //享元工厂
    public static Flyweight getFlyweight(String Extrinsic){
        //需要返回的对象
        Flyweight flyweight = null;

        if(pool.containsKey(Extrinsic)){
            flyweight = pool.get(Extrinsic);
        }else{
            //根据外部状态创建享元对象
            flyweight = new ConcreteFlyweight1(Extrinsic);
            //放置到池中
            pool.put(Extrinsic, flyweight);
        }

        return flyweight;
    }

}

享元模式可以大大减少应用程序创建的对象，降低程序内存的占用，但他同时提高了系统复杂性，需要分离出外部状态和内部状态。
使用场景：
1. 系统中存在大量的相似对象。
2. 细粒度的对象都具备较相近的外部状态，而且内部状态与环境无关。
3. 需要缓冲池的场景。

对象池与享元模式的区别:对象池着重在对象的复用上，池中的每个对象都是可替换的。而享元模式主要解决的是对象的共享问题，如何建立多个可共享的细粒度对象则是其关注的重点。

桥梁模式

定义：将抽象和实现解耦，使得两者可以独立的变化。
角色如下：
1. Abstraction:抽象角色。定义出该角色的行为，同时保存一个对实现角色的引用。该角色一般是抽象类。
2. Impkementor：实现化角色。它是接口或抽象类。定义角色必须的行为和属性。
3. RefinedAbstraction:修正抽象化角色。他引用实现化角色对抽象化角色进行修正。
4. ConcreteImplementor:具体实现化角色。
总的来说就是抽象角引用实现角色。或者说抽象角色的部分实现是实现角色完成的。通用源码：

public interface Implementor{
    //基本方法
    public void doSomething();
    public void doAnything();
}
public class ConcreteImplementor1 implements Implementor{
    public void doSomething(){
        //业务逻辑处理
    }
    public void doAnything(){
        //业务逻辑处理
    }

}
public class ConcreteImplementor2implements Implementor{
    public void doSomething(){
        //业务逻辑处理
    }
    public void doAnything(){
        //业务逻辑处理
    }

}
public abstract class Abstraction{
    //定义对实现化角色的引用
    private Implementor imp;
    //约束子类必须实现该构造函数
    public Abstraction(Implementor _imp){
        this.imp = _imp;
    }
    //自身的行为或属性
    public void request(){
        this.imp.doSomething();
    }
    //获得实现化角色
    public Implementor getImp(){
        return imp;
    }
}
public class RefinedAbstraction extends Abstraction{
    //覆写构造函数
    public RefinedAbstraction(Implementor _imp{
        super(_impl);
    }
    public void request(){
        //业务处理
        super.request();
        super.getImp().doAnyting();
    }
}
public class Client {

    public static void main(String[] args) {
        //定义一个实现化角色
        Implementor imp = new ConcreteImplementor1();
        //定义一个抽象化角色
        Abstraction abs = new RefinedAbstraction(imp);
        //执行行文
        abs.request();
    }
}

优点：
1. 抽象和实现分离。
2. 优秀的扩充能力。
3. 实现细节对客户透明。客户不用关心细节的实现，他已经由抽象层通过聚合关系完成了封装。
使用场景：
1. 不希望或不适用使用继承的场景。
2. 接口或抽象类不稳定的场景。
3. 重用性要求较高的场景。
注意事项：桥梁模式的意图是对变化的封装，尽量把变化的因素封装到最细、最小的逻辑单元中，避免风险扩散。