设计思想学习之六大原则
六大原则
- 开闭原则
- 接口隔离原则
- 迪米特法则
- 依赖倒置原则
- 里氏替换原则
- 单一职责原则
这六种原则相信网上一找一大堆,所以我也就不写一些公共的定义或者一些书面语,我只谈谈自己的学习理解。
开闭原则
开闭原则(Open Close Principle):对扩展开放,对修改关闭
很通俗易懂的一个原则,我的理解就是想要扩展功能就加新的类新的代码,以前老的代码不要去修改。
可以想想一下类似电脑内存条,内容不够了就在插一条,如果插口无限,你就可以无限插新的内存条而不是去换老的。
接口隔离原则
接口隔离原则(Interface Segregation Principle):不依赖不需要的接口,实现最小的依赖。
问题由来
public interface Animal{
void run();
void fly();
void eat();
void sleep();
}
public class Dog implements Animal{
void run(){};
void fly(){};
void eat(){};
void sleep(){};
}
public class Bird implements Animal{
void run(){};
void fly(){};
void eat(){};
void sleep(){};
}
//对于狗来说飞是没用的,对于鸟来说跑是没用,但是却又不得不实现
问题解决
把臃肿的接口拆分,让他们变小。
public interface Animal{
void eat();
void sleep();
}
public interface sky{void fly();}
public interface load{void run();}
public class Dog implements Animal,load{
void run(){};
void eat(){};
void sleep(){};
}
public class Bird implements Animal,sky{
void fly(){};
void eat(){};
void sleep(){};
}
采用接口隔离原则对接口进行约束时,要注意以下几点:
接口尽量小,但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实,但是如果过小,则会造成接口数量过多,使设计复杂化。所以一定要适度。
为依赖接口的类定制服务,只暴露给调用的类它需要的方法,它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务,才能建立最小的依赖关系。
提高内聚,减少对外交互。使接口用最少的方法去完成最多的事情。
迪米特法则
迪米特法则(Law Of Demeter): 我的理解是不要引入非朋友类,保持最少的了解,所以也叫最少知道原则(Least Knowledge Principle 简写LKP)
问题由来
在下面的代码中其实老板完全不需要与工作有依赖
public class Boss{
private Secretary secretary=new Secretary ();
public void arrange(Secretary secretary){
Work work=new Work();
secretary.send(work);
}
}
public class Secretary {
public void send(Work work){
System.out.println("传递工作任务");
work.arrangeWork();
}
}
public class Work{
public void arrangeWork(){
System.out.println("实现中国伟大复兴");
}
}
问题解决
遵循迪米特法则
public class Boss{
private Secretary secretary=new Secretary ();
public void arrange(Secretary secretary){
secretary.send();
}
}
public class Secretary {
private Work work=new Work();
public void send(){
System.out.println("传递工作任务");
work.arrangeWork();
}
}
public class Work{
public void arrangeWork(){
System.out.println("实现中国伟大复兴");
}
}
迪米特法则的初衷是降低类之间的耦合,由于每个类都减少了不必要的依赖,因此的确可以降低耦合关系。
依赖倒置原则
依赖倒置原则(Dependence Inversion Principle):我的理解是不要去直接依赖底层的模块,而是去依赖接口,然后底层去实现接口
问题由来
假如我现在正在看有关java方面的书学习java
public void My{
public void study(JavaBook javaBook){
System.out.print("正在看");
javaBook.read();
}
}
public void JavaBook{
public void read(){
System.out.println("JAVA书籍学习");
}
}
现在我想学C了,发现还要改动My的方法。
public void CBook{
public void read(){
System.out.println("C语言书籍学习");
}
}
问题解决
抽象出一本书
public interface Book{
void read();
}
public void JavaBook implements Book{
public void read(){
System.out.println("JAVA书籍学习");
}
}
public void CBook implements Book{
public void read(){
System.out.println("C语言书籍学习");
}
}
public void My{
public void study(Book book){
System.out.print("正在看");
book.read();
}
}
我现在就是想看啥书就看啥书了
在实际编程中,我们一般需要做到如下3点:
- 低层模块尽量都要有抽象类或接口,或者两者都有。
- 变量的声明类型尽量是抽象类或接口。
- 使用继承时遵循里氏替换原则。
总之,依赖倒置原则就是要我们面向接口编程,理解了面向接口编程,也就理解了依赖倒置。
里氏替换原则
里氏替换原则(Liskov Substitution Principle):我的理解是当继承的时候,尽量不要去重写父类方法,也不要重载父类的方法。
里氏替换原则通俗的来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。
反面例子
public class Animal{
public void run(){System.out.println("欢快的跑")}
}
public class Dog extends Animal{
@Override
public void run(){System.out.println("二哈")}
}
//本意是想扩展父类的方法输出:二哈欢快的跑。
//结果却变成了二哈
它有下面四层含义:
子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松。
当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。
单一职责原则
单一职责原则(Single Responsibility Principle):我的理解是专心只做一件事情。即一个类只负责一项职责。
假如一个类有有两个职责A和B,而当职责A发生改变并出现出错,难免会影响到职责B,出现不必要的麻烦。而运用了单一职责的话,把两个职责分为两个类,就算A改动也不会对B产生影响。
遵循单一职责原的优点有:
可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
提高类的可读性,提高系统的可维护性;
变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都需要遵循这一重要原则。
下一篇: 系统分析与设计hw_04