设计模式的目的
编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)，具有更好:
- 代码重用性(即:相同功能的代码，不用多次编写)
- 可读性(即:编程规范性，便于其他程序员的阅读和理解)
- 可扩 展性(即:当需要增加新的功能时，非常的方便，称为可维护)
- 可靠性(即:当我们增加新的功能后，对原来的功能没有影响)
- 使程序呈现高内聚， 低耦合的特性
设计模式七大原则
设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础
➢设计模式常 用的七大原则有:
- 单一职责原则
- 接口隔离原则
- 依 赖倒转(倒置)原则
- 里氏替换原则
- 开闭原则
- 迪米特法则
- 合成复用原则
-
单一职责原则：一个类只做关于本类的事情
-
接口隔离原则（Interface Segregation Principle）：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
-
依赖倒转原则（Dependence Inversion Principle）这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
-
里氏代换原则（Liskov Substitution Principle）里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
-
开闭原则（Open Close Principle）对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
-
迪米特法则，又称最少知道原则（Demeter Principle）最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
-
合成复用原则（Composite Reuse Principle）：尽量使用合成/聚合的方式，而不是使用继承。
1.单一职能原则
不要存在过多于一个导致类的变更原因。通俗点的话来说就是一个类负责一项职责。
问题的由来：例如一个A负责B和C 的职责，但是一旦B 的需求需要改变时，就会去修改A的功能，那么C 的运行就会出现故障。
- 降低类的复杂度，-个类只负责- -项职责。
- 提高类的可读性，可维护性
- 降低变更引起的风险
- 通常情况下， 我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则;只有类中方法数量足够少，可以在方法级别保持单- -职责原则
2.接口隔离原则(Interface Segregation Principle)
-
客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖
应该建立在最小的接口上 -
先看–张图:
-
类A通 过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口Interface1对于类A和类C来说不是最小接口:那么类B和类D必须去实现他们不需要的方
-
按隔离原则应当这样处理:将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
小结 ：当有接口需要通过接口依赖某个接口不同子类时候，尽可能把接口方法细分成多个子类，避免实现类方法的空实现，达到避免实现类强制实行这些方法。
3.依赖倒转原则(Dependence Inversion Principle)
-
高层模块不应该依赖低层模块，二者都应该依赖其抽象
-
抽象不应该依赖细节，细节应该依赖抽象
-
依赖倒转(倒置)的中心思想是面向接口编程
-
依赖倒转原则是基于这样的设计理念:相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类
-
使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成
-
接口传递
interface IOpenAndClose {
public void open(ITV itv);
}
interface ITV {
public void play();
}
class OpenAndClose implements IOpenAndClose{
@Override
public void open(ITV itv) {
itv.play();
}
}
- 构造方法传递
interface IOpenAndClose {
public void open();
}
interface ITV {
public void play();
}
class OpenAndClose implements IOpenAndClose{
private ITV itv;
public OpenAndClose(ITV itv) {
this.itv = itv;
}
@Override
public void open() {
itv.play();
}
}
- setter方式传递
interface IOpenAndClose {
public void open();
}
interface ITV {
public void play();
}
class OpenAndClose implements IOpenAndClose{
private ITV itv;
public void setItv(ITV itv) {
this.itv = itv;
}
@Override
public void open() {
itv.play();
}
}
小结：
- 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好.
- 变量的声明类型尽量是抽象类或接口,这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化
- 继承时遵循里氏替换原则
4.里氏替换原则(Liskov Substitution Principle)
- 继承包含这样一层含义:父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
- 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障
- 里氏替换原则(Liskov Substitution Principle)在1988年，由麻省理工学院的以为姓里的女士提出的。
- 如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。
- 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法.
- 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题.
案例如下
//改之前
class A{
public Integer fun1(Integer a,Integer b){
return a+b;
}
}
class B extends A{
@Override
public Integer fun1(Integer a, Integer b){
return a-b;
}
}
//改之后
interface Base{
Integer fun1(Integer a,Integer b);
}
class A implements Base{
@Override
public Integer fun1(Integer a, Integer b){
return a+b;
}
}
class B implements Base{
A ac = new A();
@Override
public Integer fun1(Integer a, Integer b){
return a+b;
}
public Integer fun2(Integer a, Integer b){
return ac.fun1(a,b);
}
}
5.开闭原则(OpenClosedPrinciple)
- 是编程中最基础、最重要的设计原则
- 一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。 - 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
代码方式1:
package com.xql.designpattern.controller;
/**
* 开闭原则
*
* @author
* @date 2022/08/16 14:22
**/
public class Light {
public static void main(String[] args) {
open(new Red());
open(new Blue());
open(new Yellow());
}
public static void open(LightColor lightColor){
if (1==lightColor.type){
System.out.println("111111");
}else if (2 == lightColor.type){
System.out.println("222222");
}else {
System.out.println("333333");
}
}
}
class LightColor{
int type;
}
class Red extends LightColor{
public Red() {
super.type =1;
}
}
class Blue extends LightColor{
public Blue() {
super.type =2;
}
}
class Yellow extends LightColor{
public Yellow() {
super.type =3;
}
}
-
优点是比较好理解，简单易操作。
-
缺点是违反了设计模式的ocp原则，即对扩展开放(提供方),对修改关闭(使用方)。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.
-
比如我们这时要新增加一个颜色，修改的地方较多
-
改进的思路分析
思路:把创建LightColor类做成抽象类，并提供- - 个抽象的open方法，让子类去实现即可这样我们有新颜色，只需要让新的类继承LightColor，并实现open方法即可，使用方的代码就不需要修->满足了开闭原则
package com.xql.designpattern.controller;
/**
* 开闭原则
*
* @author
* @date 2022/08/16 14:31
**/
public class Close {
public static void main(String[] args) {
open(new Blue1());
open(new Red1());
open(new Yellow1());
}
public static void open(LightColor1 lightColor1){
lightColor1.open();
}
}
abstract class LightColor1{
int type;
abstract void open();
}
class Red1 extends LightColor1{
public Red1() {
super.type=1;
}
@Override
void open() {
System.out.println("Red1");
}
}
class Blue1 extends LightColor1{
public Blue1() {
super.type =2;
}
@Override
void open() {
System.out.println("Blue1");
}
}
class Yellow1 extends LightColor1{
public Yellow1() {
super.type =3;
}
@Override
void open() {
System.out.println("Yellow1");
}
}
6.迪米特法则(DemeterPrinciple)
- 一个对象应该对其他对象保持最少的了解
- 类与类关系越密切，耦合度越大
- 迪米特法则()又叫最少知道原则，即–个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息
- 迪米特法则还有个更简单的定义:只与直接的朋友通信
5). 直接的朋友:每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多，赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
迪米特法则注意事项和细节
- 迪米特法则的核心是降低类之间的耦合
- 但是注意:由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系，并不是要求完全没有依赖关系
迪米特法则强调了下面两点：
- 从被依赖者的角度：只暴露应该暴露的方法或属性，即编写相关的类时确定方法和属性的权限
- 从依赖者的角度来看，只依赖应该依赖的对象.
总结：
迪米特法则的目的是让类之间解耦，降低耦合度，提高类的复用性。但是设计原则并非有利无弊，使用迪米特法则会产生大量的中转类或跳转类，导致系统复杂度提高。在实际的项目中，需要适度的考虑这个原则，不能因为套用原则而反而使项目设计变得复杂。
7.合成复用原则(Composite Reuse Principle)
原则是尽量使用合成/聚合的方式，而不是使用继承
设计原则核心思想.
- 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
- 针对接口编程，而不是针对实现编程。
- 为了交互对象之间的松耦合设计而努力
小结
-
单一职能原则：一个类只做关于本类的事情。
-
开闭原则（Open Close Principle）：对扩展开放，对修改关闭。
-
里氏代换原则（Liskov Substitution Principle）：只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
-
依赖倒转原则（Dependence Inversion Principle）：这个是开闭原则的基础，对接口编程，依赖于抽象而不依赖于具体。
-
接口隔离原则（Interface Segregation Principle）：使用多个隔离的借口来降低耦合度。
-
迪米特法则（最少知道原则）（Demeter Principle）:一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
-
合成复用原则（Composite Reuse Principle）:原则是尽量使用合成/聚合的方式，而不是使用继承。继承实际上破坏了类的封装性，超类的方法可能会被子类修改。
UML类图各种线含义
扫一扫
835
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
