适配器模式
定义：将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
适配器模式又叫做变压器模式，也叫做包装模式，装饰模式也是包装模式。
情景：A、B两个图框代表已经塑模成型的物体A和物体B，那现在要求把A和B安装在一起使用，如何安装？两者的接口不一致，是不可能安装在一起使用的，那怎么办？引入一个物体C
引入物体C后，C适应了物体A的接口，同时也适应了物体B的接口，然后三者就可以组合成一个完整的物体
角色：
Target目标角色：该角色定义把其他类转换为何种接口，也就是我们的期望接口。
Adaptee源角色：你想把谁转换成目标角色，这个“谁”就是源角色，它是已经存在的、运行良好的类或对象，需要适配器角色的包装。
Adapter适配器角色: 把源角色转换为目标角色，怎么转换？通过继承或是类关联的方式
//目标角色
public interface Target {
//目标角色有自己的方法
public void request();
}
//目标角色的实现类
public class ConcreteTarget implements Target {
public void request() {
System.out.println("if you need any help,pls call me!");
}
}
//源角色
public class Adaptee {
//原有的业务逻辑
public void doSomething(){
System.out.println("I'm kind of busy,leave me alone,pls!");
}
}
//适配器角色
public class Adapter extends Adaptee implements Target {
public void request() {
super.doSomething();
}
}
//场景类
public class Client {
public static void main(String[] args) {
//原有的业务逻辑
Target target = new ConcreteTarget();
target.request();
//现在增加了适配器角色后的业务逻辑
Target target2 = new Adapter();
target2.request();
}
}
//类关联的适配器角色
public class Adapter implements Target {
private Adaptee adaptee;
public Adapter(Adaptee adaptee) {
this.adaptee = adaptee;
}
public void request() {
adaptee.doSomething();
}
}
类之间的关系：
关系主要有6种：依赖、关联、聚合、组合、继承、实现。
依赖关系：一般是A中的某个方法把B的对象作为参数使用或者在A中的某个方法中作为局部变量使用
关联关系：类B以类的属性形式出现在类A中
聚合关系：聚合是关联关系的一种特例，他体现的是整体与部分、拥有的关系，即has-a的关系，此时整体与部分之间是可分离的。
组合关系：组合也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合更强，也称为强聚合，他同样体现整体与部分间的关系，但此时整体与部分是不可分的。
来个例子吧 区分一下
//大雁群
public class GooseGroup{
public Goose goose;
public GooseGroup(Goose goose) {
this.goose = goose;
}
}
//大雁
public class Goose {
private Wings wings;
public Goose() {
wings=new Wings();
}
}
在聚合关系中，客户端可以同时了解雁群类和大雁类，因为他们都是独立的
而在组合关系中，客户端只认识大雁类，根本就不知道翅膀类的存在，因为翅膀类被严密的封装在大雁类中。
适配器模式的应用：
适配器模式可以让两个没有任何关系的类在一起运行，只要适配器这个角色能够搞定他们就成。
适配器模式是一个补偿模式
适配器模式最好在详细设计阶段不要考虑它，它不是为了解决还处在开发阶段的问题，而是解决正在服役的项目问题，没有一个系统分析师会在做详细设计的时候考虑使用适配器模式
系统扩展了，不符合原有设计的时候才考虑通过适配器模式减少代码修改带来的风险。
装饰模式
定义：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活
角色：
Component抽象构件：是一个接口或者是抽象类，就是定义我们最核心的对象，也就是最原始的对象。
ConcreteComponent具体构件：最核心、最原始、最基本的接口或抽象类的实现，你要装饰的就是它。
Decorator装饰角色：在它的属性里必然有一个private变量指向Component抽象构件。
//抽象构件
public abstract class Component {
//抽象的方法
public abstract void operate();
}
//具体构件
public class ConcreteComponent extends Component {
//具体实现
@Override
public void operate() {
System.out.println("do Something");
}
}
//装饰者
public abstract class Decorator extends Component {
private Component component = null;
//通过构造函数传递被修饰者
public Decorator(Component _component){
this.component = _component;
}
//定义自己的修饰方法
private void method1(){
System.out.println("method1 修饰");
}
//委托给被修饰者执行
@Override
public void operate() {
this.method1();
this.component.operate();
}
}
//场景类
public class Client {
public static void main(String[] args) {
Component component = new ConcreteComponent();
//修饰
component = new Decorator(component);
//多次修饰
component = new Decorator2(component);
//修饰后运行
component.operate();
}
}
装饰模式的优点:
装饰类和被装饰类可以独立发展，而不会相互耦合。换句话说，Component类无须知道Decorator类，Decorator类是从外部来扩展Component类的功能，而Decorator也不用知道具体的构件
装饰模式是继承关系的一个替代方案。我们看装饰类Decorator，不管装饰多少层，返回的对象还是Component。
装饰模式可以动态地扩展一个实现类的功能，这不需要多说，装饰模式的定义就是如此。
装饰模式的缺点:
多层的装饰是比较复杂的,尽量减少装饰类的数量，以便降低系统的复杂度。
使用场景：
需要扩展一个类的功能，或给一个类增加附加功能。
需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。
