# 设计模式实战和总结 **Repository Path**: luischen/designpattern ## Basic Information - **Project Name**: 设计模式实战和总结 - **Description**: 设计模式实战和总结 - **Primary Language**: Java - **License**: Apache-2.0 - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2022-02-15 - **Last Updated**: 2023-02-16 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # designpattern #### 介绍 软件复杂度来源之一：变化，唯一不变的就是无时无刻不在发生的变化。 我们可以选择从组织层面来限制变化，比如合同定义项目范围，变更流程严格控制变化发生。 我们可以选择从架构设计层面来拥抱变化，比如通过预知变化进行封装，预留扩展点等。 设计原则和设计模式就是从架构设计层面拥抱变化的一套行之有效的指导思想和实践指南。 #### 软件架构 基于六大设计原则，衍生出创建型、结构性和行为型共计23个设计模式。 ![principle.png](principle.png) #### 设计原则 1. 开闭原则 OCP（Open Close Principle），开闭原则主张对扩展开放，对修改关闭。 我们可以从软件工程角度来理解开闭原则的必要性。 新增一个独立的扩展需要考虑的是这部分扩展的功能实现、测试验证和影响分析；而对原有功能的修改除了涉及到新需求的实现、测试和影响，同时还要考虑对原有功能的侵入影响和相关功能的回归测试。 开闭原则是软件设计原则的总则，其他设计原则可以认为是开闭原则在不同维度的体现。 2. 单一职责原则 SRP（Single Responsibility Principle），单一职责原则主张引起类变化的原因只能有一个，单一职责体现了软件的内聚性。 通过保持单纯来降低复杂度，提升可读性和可扩展性。 实际应用中，单一职责原则只能认为是一个美好的愿望。如果要做到严格的单一职责，每个类只提供一个方法即可，但这样必然会造成类爆炸项目无法维护。 所以在具体实施的时候我们会结合实际进行取舍。 综上，我认为单一职责原则更好的解释应该是引发类变化的原因要尽可能的少。 3. 里氏替换原则 LSP（Liskov Substitution Principle），里式替换原则主张可以使用基类的地方都应该可以透明的使用子类，而不对软件固有的功能造成影响。 里式替换原则是面向对象设计中对于继承关系的补充约定，只有满足了里式替换原则的继承才是可复用的继承。 实际应用中，我们通过具体约束来实现里式替换原则： 1， 子类必须实现父类的抽象方法，而不得重写父类的非抽象方法 2， 子类可以增加自己特有的方法，来体现自己的个性 3， 当子类重载父类的非抽象方法时，前置条件（入参）应该比父类要宽松 4， 当子类重载父类的非抽象方法时，后置条件（出参）应该比父类更严格 总体来说应用原则主要约束子类不可以对父类进行侵入性的实现，如果子类只是实现父类抽象方法（1）或者只是实现自身的个性（2）都没有问题，但是当子类需要重载父类方法时需要遵循宽进（3）严出（4）。 4. 迪米特法则 LOD（Law of Demeter），迪米特法则主张最少知识原则，即一个类只和自己的朋友发生关系，且对朋友的了解应该尽可能的少。 具体到应用实践中，从两个方面来解释 1， 只和朋友发生关系体现在类之间的关系尽可能少，非必要不产生联系； 2， 对朋友的了解尽可能少则表现为类对外只暴露需要暴露的方法和属性 5. 接口隔离原则 ISP（Interface Segregation Principle），接口隔离原则主张类之间的依赖应该建立在最小接口之上。 结合单一职责来看，尽可能小的接口更符合单一职责原则，可以更加从容的拥抱变化；基于最小接口的依赖，可以最大程度的减少变化的传递，降低软件复杂度。 6. 依赖倒置原则 DIP（Dependence Inversion Principle），依赖倒置原则主张程序要依赖抽象而不依赖具体实现。 一般意义上来说，抽象相对于实现更加稳定不易变化，所以依赖倒置原则的出发点是最大程度地减轻变化带来的影响。 #### 设计模式 ![设计模式.png](设计模式整体.png)