常见设计模式

策略模式：

strategy
策略模式容易和java本身继承机制混淆，假设一个场景，鸭子作为基类，想要去扩展，很容易想到编写子类继承鸭子父类，比如某些会飞的鸭子、不同颜色的鸭子，但当种类过多时，子类过多并且维护起来太麻烦。
细想不同的子类实际就是在父类基础上，对一些基础行为如：是否会飞、颜色等属性不同。那么将属性单独做成一个接口，如IFly接口 实现类Fly里保存是否可飞的属性，在构建鸭子类时，将IFly实现类作为一部分设置进去，后面再使用新鸭子类就可获得其被分配的策略属性。
简单说就是将对象和行为分开，将行为脱离出来单独构建。不仅代码解耦，还提高的代码复用性。

适配器模式：

adapter
原本基于接口方式，用户在使用时需要将所有方法全部覆盖重写，采用适配器模式后，适配器本身已经将接口的方法重写了一遍，所以用户只需要依据使用环境在其中找到自己所需的功能方法进行重写即可。
将功能使用和其实现解耦。

工厂模式：

a.简单工厂模式
简单工厂提供给用户一个静态方法，用于基于用户传入的参数，生成返回一个相应对象。
优点：将对象创建过程封装起来，将功能实现和创建对象解耦，用户只用关心生成的对象需要什么功能，不需要关心如何创建。
缺点：每次添加新的产品生产线需要更改工厂内部逻辑。

b.工厂方法模式
该模式与简单工厂相比，实际是多出两个需要实现的接口，工厂及其产品，将两种模式对比，如果需要生产新的产品，在简单中需要更改工厂内部判断、参数获取逻辑；而在工厂方法模式中只需要实现新的产品、工厂接口即可。
缺点：一个实际工厂只能生产一个产品，导致如果添加新生产线，工厂和产品需要成对实现，维护麻烦。

c.抽象工厂模式：
工厂方法模式是一个工厂实现类对应一个产品实现类，两者搭配生产；而抽象工厂是在产品的实现类和抽象类之间额外再包装一层，可以实现某条产品生产线下再细分类，最后实现一个工厂可以生产更多类型产品。
在工厂方法模式之上再一步将对象和其生产过程封装。

单例模式：

单例就是确保类的实例只有一个。
单例模式实现方式有两种，饿汉或者懒汉模式
懒汉模式即在用户需要getInstence时才会生成对应对象，饿汉则在类加载就生成（有可能导致生成对象过多，体验差）
单例模式生成对象需要注意多线程下的双重锁检查，即进入判断后再次加锁进行判断。

public class Registry {
    private volatile static Registry registry;
    //volatile用于防止指令重排序时影响后续操作

    private Registry() {}

    public static Registry getInstance() {
        if(registry == null) {
            synchronized (Registry.class) {
                if(registry == null) {
                    return new Registry();
                }
            }
        }
        return registry;
    }
}

观察者模式：

Observer：（发布/订阅）
将系统内角色分为主题和观察者，主题可以同时给所有观察者下发信息。
主题并不知道观察者信息，也不在乎观察者在干什么。
观察者不知道主题的具体内容，只会根据主题下发的信息进行相应处理。

建造者模式：

Builder：
建造者模式可以看作builder本身是在帮用户去构造所需类的构造方法，在执行最终build方法之前一直在给构造方法注入所需参数，最后用build方法得到所需的实例；用户只需要给复杂对象的内容，建造者就会帮助按顺序创造该复杂对象。
与工厂的区别在于建造者模式更注重每个对象所需的内容，此处由用户传入，再由builder构建，而工厂生产是固定的，用户只能直接获取对象。

代理模式：

Proxy：
为对象提供代理后，当该对象被调用，实际是在调用代理后的“替身”，可以做到在使用前、后加入不同处理，如使用前进行权限判断，使用后进行数据更新等。
如JDKProxy，CGLibProxy

装饰者模式

Decorate：
首先基于抽象组件，生成被修饰者；基于被修饰者构建修饰者基类，再基于修饰者基类扩展具体修饰类型。
被修饰者通常将会被作为修饰者基类的一个成员，方便调用。
用法：先生成被修饰者，等待修饰
将被修饰者实例作为参数传入构造函数为被修饰者添加修饰。
最后被调用时，实际通过层层继承，不断调用super并添加对应操作实现对被修饰者的修饰。

设计模式原则：
1.单一职责原则：即一个类承担的职责不应过多（耦合性不应太高）
2.开放封闭原则：一个实体应该对外扩展开放（可以通过外部代码添加该代码的属性），对内修改关闭（改属性不应通过修改本身代码实现）
3.里氏替换原则：子类必须替换父类
4.依赖倒置原则：细节应该依赖于抽象（即面向接口编程），不应抽象依赖于细节（即面向实现编程），可以降低客户与实现的耦合
5.接口隔离原则：使用过的专门功能的接口，不是单一的总接口（接口分离，多个职责分离到多个接口）
6.合成复用原则：在一个新对象中使用已有对象，称为新对象一部分（尽量合成，少用继承）
7.至少知识原则：每个模块越独立越好