【设计模式】吃透设计模式

        在学习每一种知识的时候，都需要吃透它，并且进行实践转换成自己的理解，需要知道它是什么，为什么要使用它，使用他的好处是什么。设计模式常用的有很多，我们看到的是最终的结果，而不知道其演变的过程，无法深刻了解其实际的应用情况和应用场景。在多年编码的过程中发现了这么几种情况。

        第一种：完全不知道其好处，觉得设计模式并没有什么卵用，无法应用到实际的场景中。

        第二种：知道设计模式是什么，但是具体怎么使用却无从下手。

        第三种：脱离实际情况为了用而用。

        还有其他的等等情况，并不能说这些情况是错误的，而是说其所在的环境比如业务场景，项目进度要求、想法、抽象能力都束缚着我们，没有找到可以具体落地的路径。

一、什么是设计模式

      我的理解可能也很浅显，我认为设计模式是在我们针对于当前的需求，对业务的深入理解，转换成代码后从结构上考虑其未来的复用性，通用性，以及考虑到业务后续的延展能力。

二、为什么要用设计模式

      那为什么要使用设计模式呢，有时候设计模式还具备复杂性，对新人的学习成本较高。对于其他开发人员来说要了解增加了一定的复杂度，相比其带来的长远好处和组织大局上来说我认为还是值得付出一定的学习成本。

        那么我的理解其优点体现在如下几点：方便复用、方便维护、易于拓展、解耦。设计模式最终落地到代码上，对于代码的编写每个人都有不同的编写习惯，都是对于业务场景的理解，当你只是看到当前需求时，你往往写出的就是CRUD的操作只是为了满足当前，那么当下一个相似需求来临的时候如果不去思考，会不会再去写一份相似逻辑的代码呢。那么下一步我们就会考虑实现上的问题了，在实现过程中我们会考虑这个技术或者逻辑是不是有前人可复用的通用包或者去思考是否可是把他分装成通用的方法或者组件，或者把通用部分抽离出来供大家使用，其实这个时候已经开始具备一定的设计思维了，这个时候可以考虑是否有相关方法或者现有的设计模式可以使用达成你的想法，当然之前也说了 设计模式是一种结构式的代码。往往简单的功能不是为了用而用，简单的功能可能只是把通用方法抽离出来就可以。然后我们可能会考虑业务场景脱离代码而言，这种业务场景后续还会不会有其他的变动或者流程的增加，这种增加对于我现有代码会不会有毁灭性的修改，那么我们就要设计良好的代码结构来提前适应这种变动。当然也不能过度设计。在我们思考业务变化和适用性的时候就可以考虑现有的设计模型哪些可以用来使用或者组合使用来达成我们设计的要求。   

三、日常代码中如何使用设计模式

        我认为在使用设计模式时必须先了解目前的通用设计模式有哪些，他有哪些基本原则，和每种设计模式的适用场景是什么。往往一些小需求我认为可能没必要用设计模式，设计模式是一种针对于结构上的优化。我们可以参照一些优秀的源码比如 netty\spring 等帮助我们理解设计模式的使用。我们需要具备一些抽象的能力，针对一些通用的业务或者技术代码重复性较高的地方进行提取，形成复用模块，这是一种从底向上的方法，但是往往缺乏大局观。但是对于前期培养也是一种良好的开端。在之后我们就可能基于当前的业务场景，对业务的变化延展进行思考，从上而下的进行设计。那么理解设计模式原则和基本的23种设计模式对于我们打好基础是非常重要的。

四、常用的设计模式以及分类

4.1 设计模式的7大基本原则

        1）单一职责（专人专用）原则        (Single Responsibility Principle, SRP)

        一个类只负责一个功能领域中的相应职责（每个人专职干好自己负责的事情，你是开发就干好开发不要既干开发又当财务还当销售，当公司体量很小的时候是小而美，当公司体量大的时候啥也干不好随便一个变动都会分散你现有工作的经历，打乱你的工作节奏）

        2）开闭（添砖加瓦不拆房）原则       (Open-Closed Principle, OCP)

        我们不是去拆除原有的房屋结构，而是在原有的基础上增加新的砖瓦，增强房屋的稳固性和功能性。软件实体应对扩展开放，而对修改关闭。针对一个类如果你修改了可能别人也在使用他，这时候整个系统都可能面临不稳定性，引起连锁效应。

        3）里氏代换（兼容替换、家族传统）原则        (Liskov Substitution Principle, LSP)

        在家里妈妈招待客人的准则，客人来了煮一碗鸡汤。子女们都延续了传统，即使妈妈不在家，客人来了还会给他煮一碗鸡汤，所以无论是谁只要是家中的一员都会遵守妈妈招待的标准，在软件设计中，基类更像是一个通用模版，或者标准化流程。针对一个体系里无论是什么都适用。所有引用基类对象的地方能够透明地使用其子类的对象

        4）依赖倒转（战略管理、大局观）原则        (Dependence  Inversion Principle, DIP)

        战略规划不应该直接依赖于具体的运营活动，而是依赖于更抽象的市场趋势、客户需求和公司核心竞争力等概念。这样，即使日常运营的具体做法需要根据市场变化而调整，公司的战略规划也可以保持稳定，从而实现长期的可持续发展。抽象不应该依赖于细节，细节应该依赖于抽象

        5）接口隔离（精细化管理）原则        (Interface Segregation Principle, ISP)

        不同的部门负责不同的业务领域。例如，人力资源部门负责招聘和员工培训，财务部门负责预算和审计。每个部门都有其特定的职责和接口，它们不需要关心其他部门的具体工作细节。使用多个专门的接口，而不使用单一的总接口

        6）合成复用（乐高积木）原则       (Composite Reuse Principle, CRP)

        每块积木可以单独使用，也可以与其他积木组合成更复杂的结构。在这个过程中，我们不是通过继承（复制）来创建新的积木，而是通过组合已有的积木来构建新的形状和模型。还可以用上述家族传统原则进行描述，招待客人的鸡汤没必要每次都是自己熬，可以买一些市面上比较好的预制品直接使用。尽量使用对象组合，而不是继承来达到复用的目的

        7）迪米特（潜伏）法则        (Law of Demeter, LoD)

        还可以用上述家族传统原则进行描述，招待客人的鸡汤没必要每次都是自己熬，可以买一些市面上比较好的预制品直接使用，那么买现成的预制品也没有必要直接和厂家直接交易，可以通过网络平台进行交易，在电影中有这种场景，奸细或者卧底都会有很多中间人，都是有位唯一的上下线，当卧底被抓住他也不知道具体发送命令的是谁，只是知道要执行什么命令。一个软件实体应当尽可能少地与其他实体发生相互作用。

4.2 设计模式的3大分类

        根据要解决的问题和业务场景，设计模式分为3大类分别是创建型模式、结构型模式和行为型模式。具体的设计模型在随后的博文中进行展开，这里只是进行大概的介绍。

        1）创建型模式（怎么做）

        创建型解决了如何做的问题，我们如何“烹饪”（创建）出我们需要的“菜肴”（对象）。这些模式帮助我们决定是直接炒，自己切菜放调料（简单创建），还是用特殊的方法比如蒸，统一的生产方法，比如馒头批量生产（工厂模式）、烤，拿不同材料进行组合穿串（建造者模式）或者慢炖，直接喝汤（原型模式）来做出这道菜。这样，我们就可以根据不同的场合和需求，选择最合适的方法来“烹饪”。

        2）结构型模式（怎么搭）

        搭建房子，结构型模式告诉我们如何合理地安排“房间”（类和对象）和“家具”（功能）。这些模式帮助我们决定是把电视放在客厅（代理模式），还是把书架放在书房（适配器模式），或者如何让不同的房间协同工作（装饰者模式）。这样，我们就可以构建出一个既美观又实用的“房子”（系统）。

        3）行为型模式 （怎么互动）     

        组织一场聚会，行为型模式告诉我们如何安排“客人”（对象）之间的互动。这些模式帮助我们决定是让客人轮流发言（责任链模式），还是让主持人来引导话题（命令模式），或者让客人自由交流（观察者模式）。