设计模式六大原则
设计模式六大原则
我们遇到什么困难，也不要怕，微笑着面对他，消除恐惧的最好办法就是面对恐惧，坚持，才是胜利，加油！奥利给！😂
1. 单一职责原则
-
定义：就一个类而言，应该仅有一个引起它变化的原因为。
-
错误：开发者在Activity中写Bean文件、网络数据处理，甚至 Adapter 也写在 Activity 中。
-
正解：activity就写activity；其他的辅助类或者工具类重新写出来；最好是把activity、service、adapter、beans等文件分类分包装好；
2. 开放封闭原则
-
定义：类、模块、函数等应该是可以拓展的，但是不可修改。拓展是开放的，修改是封闭的。
-
正解：面对复杂多变的“需求”；我们应该尽量通过扩展的方式来实现变化，而不是通过修改原有的代码来实现。
-
举例：我们要实现一个列表，一开始只有查询的功能，后来要新增“添加”功能，过几天又要增加“删除”功能。
-
错误：大多数人的做法是写一个方法，然后通过传入不同的值控制方法来实现不同的功能。但是如果又要新增功能，我们还得修改方法。
-
正解：用开发封闭原则解决就是增加一个抽象的功能类，让添加、删除和查询作为这个抽象功能类的子类。这样再新增功能，就无须修改原有的类，只需要添加一个功能类的子类实现功能类的方法。
3. 里氏替换原则
-
定义：所有引用基类(父类)的地方必须能透明地使用其子类的对象。
-
注释：在软件中将一个基类对象替换成其子类对象，程序将不会产生任何错误和异常；反过来不成立;→<类似于多态性的定义>
-
建议：在程序中使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。比如：
可以使用 Object url = "https://blog.csdn.net/liusaisaiV1/article/details/105503549" 代替 String url = "https://blog.csdn.net/liusaisaiV1/article/details/105503549" 在运行时，在对url进行类型判断； -
注意：
- 子类的所有方法必须在父类中声明，或子类必须实现父类中声明的所有方法；
- 尽量把父类设计为抽象类或者接口，让子类继承父类或实现父接口，并实现在父类中声明的方法；
4. 依赖倒置原则
-
定义：高层模块不应该依赖低层模块，两者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象；
-
抽象即接口或者抽象类；细节即具体实现类或者new 的对象；<并没有整明白>
5. 迪米特原则
-
定义：一个软件实体应当尽可能少地与其他实体发生相互作用。
-
注释：设计系统时，应该尽量减少对象之间的交互。如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用；如此当其中某一个模块发生修改时，就会尽量少地影响其他模块。
-
正解：
- 类的划分上，应当尽量创建耦合度低的类，这样类一旦被修改，则不会较大的影响关联的类；
- 类的结构设计上，每个类都应当尽量降低其成员变量和成员函数的访问权限。
- 对其他类的引用上，一个对象对其他对象的引用应当降到最低。
6. 接口隔离原则
-
定义：一个类对另一个类的依赖应该建立在最小的接口上。
-
要为各个类建立专用的接口，而不要试图建立一个很庞大的接口供所有依赖它的类调用；建立单一接口，不要建立庞大臃肿的接口；要细化接口，接口中的方法尽量少；
-
注意：
- 对接口进行细化可以提高程序设计的灵活性；但是如果过小，则会造成接口数量过多，使设计复杂化。所以要适度。
- 只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。
- 接口方法尽量少用public修饰。接口是对外的承诺，承诺越少对系统的开发越有利，变更风险也会越少。
设计模式分类
1. 创建型设计模式
- 与对象创建有关；共5种：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式；
单例模式
2. 结构型设计模式
- 共7种：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
3. 行为型设计模式
- 共11种：策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。等
总结：
- 大佬刘望舒的博客已经写得很全面了，作为学习《进阶之光》整理笔记的板块，实在汗颜；大佬的原文博客: 设计模式.。
- 声明：本文学习资料来自 刘望舒《Android进阶之光》.；如有侵权，请联系我立即删除。