尚硅谷学习笔记——Java设计模式(一)设计模式七大原则
一、介绍
在软件工程中,设计模式(design pattern)是对软件设计中普遍存在(反复出现)的各种问题,提出的解决方案。我们希望我们的软件能够实现复用性、高稳定性、扩展性、维护性、代码重用性,所以出现了设计模式的概念。
设计模式常用的七大原则:
1)单一职责原则
2)接口隔离原则
3)依赖倒转原则
4)里氏替换原则
5)开闭原则ocp
6)迪米特法则
7)合成复用原则
设计模式的目的:
1)代码重用性(即:相同功能的代码,不用多次编写)
2)可读性(即:编程规范性,便于其他程序员的阅读和理解)
3)可扩展性(即:需要增加新的功能时,非常方便)
4)可靠性(即:增加新的功能后,对原来的功能没有影响)
5)使程序呈现高内聚、低耦合的特性
二、单一职责原则
对一个类来说,一个类应该只负责一项职责。
1)降低类的复杂度,一个类只负责一项职责;
2)提高类的可读性,可维护性;
3)降低变更引起的风险;
4)通常情况下,我们应当遵守单一职责原则,只有逻辑足够简答,才能在代码级违反单一职责原则;只有类中的方法数量足够少,才可以在方法级别保持单一职责原则。
三、接口隔离原则
客户端不应该依赖它不需要的接口。即一个类对另一个类的依赖应该建立在最小的接口上。
改进前:
改进后:
四、依赖倒转原则
1)高层模块不应该依赖低层模块,二者都应该依赖其抽象;
2)抽象不应该依赖细节,细节应该依赖抽象;
3)依赖倒转(倒置)的中心思想是面相接口编程;
4)依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定得多。在java中,抽象就是接口或抽象类,细节就是具体的实现类;
5)使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展示细节的任务交给它们的实现类去完成。
改进前:
//方式1:实现Person接收消息的功能
class Person {
public void receive(Email email) {
System.out.println(email.getInfo());
}
}
问题:如果我们获取的对方改变,Person也要增加相应的接受方法
解决思路:引入一个抽象的接口IReceiver,表示接受者,这样Person类与接口IReceiver发生依赖。其他实现都属于接收的范畴,只需各自实现IReceiver接口就可以。这样就符合依赖倒转原则
改进后:对接口进行依赖,稳定性提高
//方式2
//定义接口
interface IReceiver {
public String getInfo();
}
class Email implements IReceiver {
public String getInfo() {
return "电子邮件信息:hello, world";
}
}
class Person {
public void receive(IReceiver receiver) {
System.out.println(receiver.getInfo());
}
}
public class DependencyReceiver {
public static void main(String[] args) {
//客户端无需改变
Person person = new Person();
person.receive(new Email());
}
}
依赖传递的三种方式
依赖传递有三种方式,这里只写调用方法
ChangHong changHong = new ChangHong();
1)通过接口传递实现依赖
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.open(changHong);
2)通过构造器进行依赖传递
OpenAndClose openAndClose = new OpenAndClose(changHong);
openAndClose.open();
3)通过setter方法传递
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.setTv(changHong);
openAndClose.open();
五、里氏替换原则
继承性说明:
1)父类中凡是实现好的方法,实际上是某种规范和契约,虽然不强制所有子类必须遵守,但如果子类对这些已实现的方法进行任意修改,就会对整个继承体系造成破坏。
2)继承的弊端:使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性。如果一个类被其他类继承,当这个类需要修改时,必须考虑所有子类。且父类修改后,所有涉及到子类的功能都可能发生故障。
3)为了解决这一问题,我们提出里氏替换原则
里氏替换原则
1)如果每个类型为T1的对象O1,都有类型为T2的对象O2,使T1定义的所有程序P在所有对象O1被替换成O2时,程序P没有任何变化。那么T2是T1的子类型。也就是说,所有引用基类的地方必须能透明的使用其子类的对象。
2)在使用继承时,子类尽量不要重写父类的方法。
比如说,A类中有m1、m2、m3三个方法,B类继承A类,且重写了A类的所有方法,这样就无法做到透明化。
对此,我们可以让B类和A类共同继承一个更加基础的base类,使AB类耦合性降低,将AB类的公共方法提高base类中。
六、开闭原则
介绍:
1)开闭原则是编程中最基础、最重要的设计原则。
2)一个软件实体如类、模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方)。用抽象构建框架,用实现扩展细节。
3)当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。
4)编程中遵循其他原则,以及使用设计模式的目的就是遵循开闭原则。
改进前:
//用于绘图的类
class GraphicEditor {
//接受Shape对象,根据type绘制不同的图形
public void drawShape(Shape s) {
if(s.m_type == 1) drawRectangle(s);
else if(s.m_type == 2) drawCircle(s);
}
public void drawRectangle(Shape s) {
System.out.println("绘制矩形");
}
public void drawCircle(Shape s) {
System.out.println("绘制圆形");
}
}
//Shape类,基类
class Shape {
int m_type;
}
class Rectangle extends Shape {
Rectangle(){
super.m_type=1;
}
}
class Circle extends Shape {
Circle(){
super.m_type=2;
}
}
public classOcp {
public static void main(String[] args) {
//存在的问题
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
}
}
存在的问题:
违反了设计模式的OCP原则,即对扩展开放,对修改关闭。即当我们给类增加新功能的时候,尽量不修改代码,或者尽可能少修改代码。
思路:把shape类做成抽象类,并提供一个抽象的draw方法,让子类去实现。这样当我们有新图形时,只需要让新的图形类继承shape、并实现draw方法。使用方的代码就不需要修改。
改进后:
//用于绘图的类
class GraphicEditor {
//接受Shape对象,根据type绘制不同的图形
public void drawShape(Shape s) {
s.draw();
}
}
//Shape类,基类
abstract class Shape {
int m_type;
public abstract void draw();
}
class Rectangle extends Shape {
@Override
public void draw() {
System.out.println("绘制矩形");
}
}
class Circle extends Shape {
@Override
public void draw() {
System.out.println("绘制圆形");
}
}
public classOcp {
public static void main(String[] args) {
//存在的问题
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
}
}
七、迪米特法则
基本介绍:
1)一个对象应该对其他对象保持最少的了解
2)类与类的关系越密切,耦合度越大
3)迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好。对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public方法,不对外泄露任何信息。所以陌生的类最好不要以局部变量的形式出现在类的内部。
注意事项:
1)迪米特法则的核心是降低类之间的耦合。
2)由于每个类都减少了不必要的依赖,因此迪米特法则只是要求降低类间(对象间)耦合关系,并不是要求完全没有依赖关系。
八、合成复用原则
尽量使用合成、聚合的方式,而不是使用继承。
从 is a 变成 has a
九、总结
1)找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。
2)针对接口编程,而不是针对实现编程。
3)为了交互对象之间的松耦合设计而努力