一、软件7大设计原则
开闭原则
依赖倒置原则
单一职责原则
接口隔离原则
迪米特原则
里氏替换原则
合成复用原则
1. 开闭原则
定义:一个软件实体,如类、模块和函数应该对扩展开发,对修改关闭。
用抽象构建框架,用实现扩展细节。
优点: 提过软件系统的可复用性及可维护性
Code:
增加ICourse 接口
public interface ICourse { Integer getId(); String getName(); Double getPrice(); }
JavaCourse类
public class JavaCourse implements ICourse{ private Integer id; private String name; private Double price; public JavaCourse(Integer id, String name, Double price) { this.id = id; this.name = name; this.price = price; } @Override public Integer getId() { return this.id; } @Override public String getName() { return this.name; } @Override public Double getPrice() { return this.price; } }
增加打折类JavaDiscountCourse
public class JavaDiscountCourse extends JavaCourse { public JavaDiscountCourse(Integer id, String name, Double price) { super(id, name, price); } public Double getOriginPrice(){ return super.getPrice(); } @Override public Double getPrice() { return super.getPrice() * 0.8; } }
测试:
public class Test { public static void main(String[] args) { ICourse iCourse = new JavaDiscountCourse(90,"Java学习",300d); JavaDiscountCourse javaCourse = (JavaDiscountCourse)iCourse; System.out.println("课程Id:" + iCourse.getId() + " 名称:" + iCourse.getName() + " 折后价格:" + iCourse.getPrice() + " 原价: " + javaCourse.getOriginPrice()); } }
当课程增加打折功能时,我们没有在接口中增加打折方法,而是增加JavaDiscountCourse。 这样就做到了对接口ICourse 修改是关闭的,对扩展的功能进行开发,通过JavaDiscountCourse 来实现增加的功能
2. 依赖倒置原则
定义: 高层模块不应该依赖底层模块,二者都应该依赖其抽象。
抽象不应该依赖细节;细节应该依赖抽象
针对接口编程,不要针对实现编程
优点: 可以减少类间的耦合性、提高系统的稳定性,提高代码可读性和可维护性,可降低修改程序所造成的风险
2.1 Code:
新建Tom
public class Tom { public void studyJavaCourse(){ System.out.println("Tom学习Java"); } public void studyAndroidCourse(){ System.out.println("Tom学习Android"); } }
新建测试类Test.java
public static void main(String[] args) { Tom tom = new Tom(); tom.studyAndroidCourse(); tom.studyJavaCourse(); }
测试类依赖于Tom,如果此时要增加学习Ios方法,我们可以在Tom类中增加studyIosCourse。但是这样Test类完全依赖于Tom类,完全耦合在一起了。
2.2 修改后的Code
1) 新增接口
public interface ICourse { void studyCourse(); }
2)增加JavaCourse类,实现ICourse接口
public class JavaCourse implements ICourse{ @Override public void studyCourse() { System.out.println("学习Java"); } }
3) 增加AndroidCourse类
public class AndroidCourse implements ICourse { @Override public void studyCourse() { System.out.println("学习Android"); } }
4) 测试类Test.java
public static void main(String[] args) { Tom tom = new Tom(); tom.study(new JavaCourse()); tom.study(new AndroidCourse()); }
如果此时要增加学习Ios方法,只需要增加IosCourse类,并实现ICourse接口即可。Test类与Tom类解耦,Tom类与具体的课程实现解耦。
3. 单一职责原则
定义:不要存在多于一个导致类变更的原因
一个类/接口/方法只负责一项职责
优点:降低类的复杂度、提高类的可读性,提高系统的可维护性、降低变更引起的风险
4. 接口隔离原则
定义:用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口
一个类对一个类的依赖应该建立在最小的接口上
建立单一接口,不要建立庞大臃肿的接口
尽量细化接口,接口中的方法尽量少
注意点:
注意适当原则,一定要适度
优点:符合我们常说的高内聚低耦合的设计思想
从而使得类具有很好的可读性、可扩展性和可维护性。
如下面的类图
接口IAnimalAction有三个方法 eat,fly,swim。 Dog实现了这个接口,但是Dog不会fly。 Bird类实现了这个接口,但是有些Bird不会fly或者swim。
这样就导致了类中的一些空实现。
如下图的改进版本:
Dog类实现了IEatAnimalAction和ISwimAnimalAction。
5. 迪米特原则
定义: 一个对象应该对其他对象保持最少的了解。又叫最少知道原则
尽量降低类与类之间的耦合
优点: 降低类之间的耦合
迪米特原则强调:
强调只和朋友交流,不和陌生人说话
朋友:出现在成员变量、方法的输入、输出参数中的类称为成员朋友类,而出现在方法体内部的类不属于朋友类。
Code 需求:Boss问teamLeader,要知道线上有几个课程上线
1. 创建Course类
public class Course { }
创建TeamLeader类
public class TeamLeader { public void checkNumberOfCourses(List<Course> courseList){ System.out.println("课程数量是:" + courseList.size()); } }
创建Boss类
public class Boss { public void commandCheckNumber(TeamLeader teamLeader){ List<Course> courseList = new ArrayList<>(); for(int i = 0; i < 20; i++){ courseList.add(new Course()); } teamLeader.checkNumberOfCourses(courseList); } }
创建测试类
public class Test { public static void main(String[] args) { Boss boss = new Boss(); TeamLeader teamLeader = new TeamLeader(); boss.commandCheckNumber(teamLeader); } }
根据迪米特原则,Boss类中和Course类耦合在一起,实际上他不需要知道Course。
分析类图
Boss类中创建Course中,耦合在一起了。
修改版本:
Boss类
public class Boss { public void commandCheckNumber(TeamLeader teamLeader){ teamLeader.checkNumberOfCourses(); } }
TeamLeader类
public class TeamLeader { public void checkNumberOfCourses(){ List<Course> courseList = new ArrayList<>(); for(int i = 0; i < 20; i++){ courseList.add(new Course()); } System.out.println("课程数量是:" + courseList.size()); } }
其他类不变。
UML图变化如下:
二、设计模式
1. 创建新模式
工厂方法模式
抽象工厂模式
建造者模式
单例模式
原型模式
2. 结构性模式
适配器模式
装饰者模式
代理模式
外观模式
桥接模式
组合模式
享元模式
行为性模式
策略模式
观察者模式
责任链模式
备忘录模式
模板方法模式
迭代器模式
中介者模式
命令模式
访问者模式
解释器模式
状态模式