设计模式 -- 设计原则
| 设计原则 | 一句话归纳 | 目的 |
| 开闭原则 | 对扩展开放，对修改关闭 | 降低维护带来的新风险 |
| 依赖倒置原则 | 高层不应该依赖低层，要面向接口编程 | 更利于代码结构的升级扩展 |
| 单一职责原则 | 一个类只干一件事，实现类要单一 | 便于理解，提高代码的可读性 |
| 接口隔离原则 | 一个接口只干一件事，接口要精简单一 | 功能解耦，高聚合、低耦合 |
| 迪米特法则 | 不该知道的不要知道，一个类应该保持对其它对象最少的了解，降低耦合度 | 只和朋友交流，不和陌生人说话，减少代码臃肿 |
| 里氏替换原则 | 不要破坏继承体系，子类重写方法功能发生改变，不应该影响父类方法的含义 | 防止继承泛滥 |
| 合成复用原则 | 尽量使用组合或者聚合关系实现代码复用，少使用继承 | 降低代码耦合 |
1. 开闭原则（Open Close Principle）OCP
对扩展开放，对修改关闭。
当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。
使用接口和抽象类，达到热插拔的效果。
实现方法
用抽象构建框架，用实现扩展细节（用细节实现扩展）
可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。
2. 里氏替换原则（Liskov Substitution Principle） LSP
任何基类可以出现的地方，子类一定可以出现。
子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
-
子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
-
子类中可以增加自己特有的方法
-
当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松
-
当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类的方法更严格或相等
通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。
关于里氏替换原则的例子，最有名的是“正方形不是长方形”。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能，所以它们不能定义成“鸟”的子类。同样，由于“气球鱼”不会游泳，所以不能定义成“鱼”的子类；“玩具炮”炸不了敌人，所以不能定义成“炮”的子类等。
举例：一个继承树中，所有树节点都是抽象类，所有的叶子节点都是具体实现类。使用父类的地方可以传入任何一个子类。这个最经典的就是Android中的View继承树了，所有传入ViewGroup的方法可以传入任何一个继承自ViewGroup的容器；可以传入View的方法可以传入任何一个ViewGroup或者继承自View的控件。如setContentView(Viewv)，既然参数是View，那么传入任何一个继承自View的控件都可以，如TextView,LinearLayout等。
实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现。
里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。
3. 依赖倒转原则（Dependence Inversion Principle）DIP
针对接口编程，依赖于抽象而不依赖于具体。
高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
要面向接口编程，不要面向实现编程。
依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
实现方法
依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点：
-
每个类尽量提供接口或抽象类，或者两者都具备。
-
变量的声明类型尽量是接口或者是抽象类。
-
任何类都不应该从具体类派生。
-
使用继承时尽量遵循里氏替换原则。
4. 单一职责原则（Single Responsibility Principle）SRP
一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。
实现方法
单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。
5. 接口隔离原则（Interface Segregation Principle）ISP
客户端不应该被迫依赖于它不使用的方法。
一个类对另一个类的依赖应该建立在最小的接口上。
要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
也称接口最小化原则，强调的是一个接口拥有的行为应该尽可能的小。
一个类/接口/方法只负责一项原则
实现方法
-
接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
-
为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
-
了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
-
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
6. 迪米特法则（最少知道原则）（Law of Demeter，LoD）
一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
一个对象应该对其他对象保持最少的了解。
尽量降低类与类之间的耦合。
如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。
实现方法
从迪米特法则的定义和特点可知，它强调以下两点：
-
从依赖者的角度来说，只依赖应该依赖的对象。
-
从被依赖者的角度说，只暴露应该暴露的方法。
所以，在运用迪米特法则时要注意以下 6 点。
-
在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
-
在类的结构设计上，尽量降低类成员的访问权限。
-
在类的设计上，优先考虑将一个类设置成不变类。
-
在对其他类的引用上，将引用其他对象的次数降到最低。
-
不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
-
谨慎使用序列化（Serializable）功能。
7. 合成复用原则（Composite Reuse Principle）CRP
尽量使用合成/聚合的方式，而不是使用继承。
又叫组合/聚合复用原则（Composition/Aggregate Reuse Principle，CARP）。它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
通常类的复用分为继承复用和合成复用两种。
实现方法
合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。
根据以下文章总结：
-
Java设计模式：23种设计模式全面解析（超级详细）HYPERLINK http://c.biancheng.net/design_pattern/ n委派模式在JDK以及Spring源码中的应用_蒙奇D灬小武的博客-CSDN博客
-
设计模式 https://blog.csdn.net/shusheng0007/category_8638565.html 永不磨灭的设计模式（有这一篇真够了，拒绝标题党）_ShuSheng007的博客-CSDN博客_永不磨灭的设计模式
-
java设计模式 https://blog.csdn.net/qq_37909508/category_8976362.html
-
设计模式 在源码中的应用 https://blog.csdn.net/qq_36970993/category_10620886.html
-
Android系统设计中存在设计模式分析 https://www.2cto.com/kf/201208/150650.html
-
Android设计模式系列 - 基于android的各种代码分析各种设计模式 https://www.cnblogs.com/qianxudetianxia/category/312863.html
更多推荐
0
0- 0
已为社区贡献2条内容
所有评论(0)