设计模式概述

1. 设计模式七大原则

(1)单一职责原则

一个类只负责一项职责,主要体现在各司其职;

降低了类的复杂度,一个类只负责一项职责;

通常情况下我们应当遵守单一职责原则,只有逻辑足够简单,才能够在代码级违反单一职责原则;只有类中方法数量足够少,可以在方法级别保持单一职责原则

(2)接口隔离原则

客户端不需要依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上,也就是说类A依赖于接口C的话就与他们需要的接口建立依赖关系(极端一点,类A依赖于接口C的话,就依赖于接口C的所有方法)

接口隔离原则改进

类A通过接口Interface1依赖于类B,类C通过接口Interface1依赖于类D,如果接口Interface1对于类A和类C来说不是最小接口(也就说Interface中有类A和类C用不到的方法),那么类B和类D必须去实现他们不需要的方法

(3)依赖倒转原则

高层模块不应该依赖底层模块,二者都应该依赖其抽象

抽象不应该依赖其细节,细节应该依赖其抽象(也即是说实现类应该依赖于接口,而不是接口的实现类)

依赖倒转的中心思想是面向接口编程

设计理念:抽象的东西要稳定,在Java中抽象指的是接口或抽象类,细节就是具体的实现类

接口和抽象的目的在于设计

依赖倒转原则的注意事项:低层模块尽量都要有抽象类或接口,或者两者都有,程序稳定性更好;变量的声明类型尽量是抽象类或接口,这样我们的变量引用和实际对象间,就存在一个缓冲区

依赖关系传递的三种方法: 接口传递、构造方法传递、setter方法传递

(4)里氏替换原则

如果对每个类型为T1的对象O1,都有类型为T2的对象O2,使得以T1定义的所有程序P所在的对象O1都代换成O2时,程序P的行为没有发生变化,那么类型T2是类型T1的子类型,换句话说,所有引用基类的地方必须能透明地使用其子类的对象

在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法

继承实际上让两个类耦合性增强了,在适当的情况下,可以通过聚合、组合、依赖来解决

解决方法: 原来的父类和子类都继承一个更通俗的基类,原有的继承关系去掉,采用依赖、聚合、组合等关系代替

(5)开闭原则

最基础最重要的原则,所有的设计模式都是为了实现这个原则

对扩展开放(提供方),对修改关闭(使用方)也就是说:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化

(画图形那个例子)

(6)迪米特法则

一个对象应该对其他对象保持最少的了解

迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好,对被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部,对外除了提供的public方法,不对外泄露任何信息(不要将自己的代码放在别人的类里)

更简单的定义:只与直接的朋友通信

直接的朋友:出现成员变量,方法参数,方法返回值的类为直接朋友,出现在局部变量中的类不是直接的朋友;陌生类最好不要以局部变量的形式出现在类的内部

迪米特法则的核心是降低类之间的耦合

(7)合成复用原则

尽量使用合成/聚合的方式,而不是用继承

例子:B类使用A类的三种方式:

1.B类继承A类,这样会导致B和A的耦合性增强

2.将A类作为方法参数传给B类(依赖),operation(A a)

3.将A类作为B的属性(聚合),用getter、setter方法

4.在B中new一个A(组合)

2. 设计模式介绍

设计模式不是代码,是某类问题的通用解决方案

设计模式分为三种类型,共23种

创建型模式:单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式

结构型模式:适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式

行为型模式:模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式(Interpreter模式)、状态模式、策略模式、责任链模式

  • 21
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值