什么是设计模式？
设计模式就是前人总结的代码设计的模型，就像武侠里面的武功的招式，套路。
为什么需要设计模式啊？
我平时代码敲的也没有问题啊，功能也完成了，线上跑的很健康
1、统一编程风格
实现功能，这属于硬编码，没有什么技巧，形成不了模式，只能说是个copyer，复制人。大部分代码都是cv的。不能称得上工程师，你敲的代码不能成为工程级别的项目。可能你写的代码只能你自己看得懂，如果你的命名不规范的化，就会形成自己的一套代码风格。
2、易维护，行内统一语言
如果你使用设计模式，大家的代码风格统一了，大家都有了共识，理解代码的结构也很轻松，不过这里有个大前提，就是你的团队，都懂设计模式。
3、代码更优雅
设计模式，让你的代码更优雅，比如建造者模式
HttpClient.builder().url("<http://aliserver/api/user/query>")
.method(Method.GET)
.parameter(Map.of("uuid", "432231", "key", "di2da2ddsa3s"))
.build();
4、可扩展性强，轻松应对多变需求
设计模式，可以让代码写的复用性好，可扩展性强。说白了，就是面对多变的需求，你可以改动很少的代码就能适应新需求，就像汽车的部件一样，代码功能块就像汽车部件了，拆拆装装，就产生新的新特的汽车。这样的代码，老板喜欢，因为节省开发成本，减少人力；深受同行吹捧，因为这已经成为工匠打磨的作品。
怎么使用设计模式
从我学习设计模式的经验，记住概念，记住类图 ，很容易忘记，容易混淆各个设计模式。后来发现，记住设计模式的本质是很重要的，让围绕这个本质，再去看这些设计模式，比较容易吸收点。
设计模式的目标：让代码，维护成本低，面对多变需求，可扩展性强.
设计模式的本质：面向抽象，隔离实现
用白话解释就是，设计模式都是抽象类，接口来组织代码关系，实现层都是被隐藏的，也就是隐藏细节，面向抽象层。
那么为什么要面向抽象，隔离实现呢？
因为抽象是稳定的,实现层是具体的细节，是多变的。
举个例子，用户登录注册这样的需求，抽象出来，就是用户服务：userService，有login（），register（）。然后我们提测，测试经过数天的功能测试，回归测试，生产验证，功能发布成功，
这是不变的方法吧。如果要来了一个微信登录这些细节的时候，那么user这个类就不稳定了。所以我们设计成abstract userService，wxUserService，qqUserService。
可以做到面对多变需求，动态扩展，不需要修改原有的类，避免了维护原有类，测试原有功能的工作量。
然后为了“面向抽象，隔离实现”这个目标，先人提出了设计原则
我们开发一个订单系统的项目，经过需求评审，代码实现，单元测试，功能测试，线上运行，投入了很多的人力成本，才交出了stabale稳定的代码。
现在需要添加一个功能，作为老板，或者管理人员，我们希望不要修改原有功能模块的代码，这样增加了回归已有功能的工作量，也增加了线上原有功能影响的风险，所以期望只在原有基础扩展现有功能。
这里，就得提到，开发程序要符合开闭原则，做到不修改，只扩展。
要做到开闭原则，就得引出设计原则：单一职责，我们定义的类的功能边界要明确，职责清晰，这样面对多变的需求变动的可能性就小，比如下单功能，orderService只负责订单的创建订单，修改订单功能，如果还参杂着的物流信息的功能，下次如果物流功能变更，就会牵扯到订单功能。
上面我们提到了，抽象是稳定的，实现是多变的，所以引出了依赖倒置的原则，我们定义的类与类之间，是通过抽象层产生关系，抽象层不依赖实现类，实现类要依赖抽象层，体现了“面向抽象，隔离实现”
还有接口隔离原则，接口的实现类，不要实现跟自己无关的抽象方法，类的继承也要做到尽可能少的继承与自己无关的方法，这样做也是为了减少上层的变动影响了下层。
在程序开发中，类与类之间肯定会产生关系，就难免产生耦合，类之间关系越复杂，牵涉到某功能变动，就会影响，不符合开闭原则，所以我们约定类与类之间尽可能少的产生依赖关系，只与自己直接关系的类有依赖关系，这也就是迪米特法则，也就是最小知道原则，
类的继承，是强耦合的东西，给程序带入了侵入型，基类的方法，被子类继承，如果继承的方法发生变更，子类功能都会受影响，所以我们约定了 子类继承基类，只能继承原有方法，新增新的功能方法，不得重写父类的功能方法，这就是里氏替换原则：出现基类的地方，子类能替换。
合成复用原则：少用继承，多用合成，依赖关系，为了减少耦合的可能性。
总结
遵守了上面提到了设计原则，我们的代码健壮性更强，可扩展性也更好，减少了代码的出错率。
设计模式，就是基于上述的7大原则，形成的一套招式，其中比较典型的就是桥梁模式。
