23种设计模式_基础篇

23种设计模式_基础篇

设计模式常用的7大原则

  • 单一职责原则
一个类应该只负责一项职责。如果一个类负责两个不同的职责,且两个职责之间有很大的联系。当其中某一个职责需要进行改变类时,有可能会影响到另一个职责的逻辑所以应该将这个类分解为两个类只负责一项职责。

好处(在代码中尽量少使用if else, 这样耦合性将会增加)

1. 降低类的复杂度,一个类只负责一项职责
2. 提高类的可读性,可维护性
3. 降低变更引起的风险
  • 接口隔离原则
客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上(适配器模式,对于没有必要实现的方法,应该有一个适配器去空实现接口方法,而具体的实现类只需继承自适配器,实现必须实现的方法)
  • 依赖倒置原则(实现方法: 构造器注入, 对接口依赖注入,使用setter注入)
1. 高层模块不应该依赖底层模块,二者都应该依赖其抽象
2. 抽象不应该依赖细节,细节应该依赖抽象
3. 依赖倒转的中心思想时面向接口编程
4. 设计理念: 相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础搭建的架构要稳定的多(个人理解: 项目中尽量使用接口代替实现类去实现业务。如果使用实现类的话,一旦用户需求变更,实现类也会跟着变更,这样就需要改动大量的代码。如果是依赖于接口,只需要重新写一个实现类去实现业务,在需要的地方使用接口来接收对象并调用方法)
5. 使用接口或抽象类的目的是指定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成

注意事项

  1. 底层模块尽量要有抽象类或者接口,或者两者都有,程序更稳定更好.
  2. 变量的声明尽量是抽象类或接口,这样我们的变量引用和实际对象间,就存在一个缓冲层,利于程序扩展和优化
  3. 继承时遵循里氏替换原则
  • 里氏替换原则
1. 所有引用基类的地方必须能透明的使用其子类的对象
2. 子类中尽量不要重写父类的方法(如果重写了,就要考虑是否为其子类带来不好的影响,导致子类无法执行)
3. 里氏替换告诉我们,继承实际上让两个类的耦合性增强了,在适当的情况下,可以通过聚合,组合,依赖的方式来解决问题
  • 开闭原则
1. 一个软件实体类,模块和函数应该对扩展开放,对修改关闭。用抽象构建框架,用实现扩展细节
2. 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的源代码来实现
  • 迪米特法则
1. 一个对象应该对其他对象保持最少的了解(不和陌生人说话,只与直接朋友通信。朋友和朋友的朋友之间进行的交互,不要放在我这里完成)
2. 类与类关系越密切,耦合度越大
3. 一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管有多么复杂,都尽量将逻辑封装在类的内部。对外部除了提供public方法,不对外泄露任何信息
4. 直接的朋友: 只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。(耦合的方式: 依赖, 关联, 组合, 聚合...)出现在成员变量,方法参数,方法返回值中的类称为直接的朋友,出现在局部变量中的类不是直接的朋友。
  • 合成复用原则
1. 尽量使用合成/聚合的方式,而不是使用继承

review时需要注意的几点

  1. 找出应用中可能需要变化之处,把他们独立出来,不要和哪些不需要变化的代码混在一起
  2. 针对接口编程,而不是针对实现编程
  3. 为了交互对象之间的松耦合设计而努力
  4. 尽可能的遵守7大原则

UML(统一建模语言)类图

简介: uml类图是用于描述类本身的组成和类对象之间的各种静态关系

类和类之间的关系

  • 依赖关系

    • 如何判定两个类之间具有依赖关系?

      • 只要是在类中用到了对方,那么他们之间存在依赖关系
      • 一个类是另一个类的成员变量
      • 一个类是另一个类方法的返回类型
      • ~~方法的参数类型
      • 方法中使用到
    • 怎样描述两个类之间具有依赖关系?

      • 代码

        public class Vehicle {
        
                public void run(String vehicle) {
                    System.out.println(vehicle + "在公路上跑");
                }
        }
        
        public class SingleDemo {
            private Vehicle vehicle = new Vehicle();
        }
        
      • 在这里插入图片描述

  • 泛化关系(继承)

    • 泛化关系理解

      • 泛化关系实际上就是继承关系,它是依赖关系的特例
    • 怎样描述?

      • 代码

        public class Vehicle {
        
                public void run(String vehicle) {
                    System.out.println(vehicle + "在公路上跑");
                }
        }
        
        public class Car extends Vehicle {
        
            @Override
            public void run(String vehicle) {
                System.out.println("车在高速公路上跑");
            }
        }
        
      • 在这里插入图片描述

  • 实现关系(实现接口)

    • 理解

      • 同上, 依赖的特例
    • 代码

      public interface Pen {
      
          void writing();
      }
      
      public class Pencil implements Pen {
          @Override
          public void writing() {
              System.out.println("铅笔写的字");
          }
      }
      
    • 在这里插入图片描述

  • 关联关系

    • 理解

      • 关联关系实际上就是类与类之间的联系,依赖特例
      • 关联具有导航性: 双向或者单向关系,
    • 代码

      • 单向

        public class IDCard {
        
        }
        
        public class Person {
            private IDCard idCard;
        }
        
      • 双向

        public class IDCard {
        	private Person person;
        }
        
        public class Person {
            private IDCard idCard;
        }
        
    • 单向一对一

      在这里插入图片描述

    • 双向一对一

      在这里插入图片描述

  • 聚合关系

    • 理解
      • 表示整体和部分的关系,整体和部分可以分开,聚合关系是关联关系的特例
    • 用空心菱形代替
  • 组合关系

    • 理解
      • 表示整体和部分的关系,整体和部分共存,如同人和心脏一样,聚合关系是关联关系的特例
    • 用实心菱形代替
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值