设计模式之七大原则
设计模式
设计模型的目的
为了让程序(软件),具有更好的代码重用性、可读性、可扩展性、可靠性,
使程序呈现高内聚,低耦合的特性
设计模式七大原则
设计模式七大原则
1.单一职责原则
2.接口隔离原则
3.依赖倒转原则
4.里氏替换原则
5.开闭原则
6.迪米特法原则
7.合成复用原则
单一职责原则
一个类只负责一个原则
代码测试:
package com.cedric.simplicity;
public class SimplicityDemo01 {
public static void main(String[] args) {
RoadVehicle roadVehicle = new RoadVehicle();
roadVehicle.run("摩托");
roadVehicle.run("汽车");
AirVehicle airVehicle = new AirVehicle();
airVehicle.run("直升机");
}
}
/*
解决方案1分析
1.遵守单一职责原则
2.这样做改动很大,既将类分解,又同时修改客户端
*/
// 公路
class RoadVehicle{
public void run(String vehicle){
System.out.println(vehicle + "在公路运行");
}
}
// 空中
class AirVehicle{
public void run(String vehicle){
System.out.println(vehicle + "在空中运行");
}
}
// 水上
class WaterVehicle{
public void run(String vehicle){
System.out.println(vehicle + "在水上运行");
}
}
package com.cedric.simplicity;
public class SimplicityDemo02 {
public static void main(String[] args) {
Vehicle vehicle = new Vehicle();
vehicle.run("汽车");
vehicle.runAir("飞机");
vehicle.runWater("轮船");
}
}
/*
方案2分析:
1.这种修改方法没有对原来的类做大的修改,只是增加方法
2.这里虽然没有在类这个级别上遵守单一原则,但是在方法原则上,仍是遵守单一原则
*/
class Vehicle{
public void run(String vehicle){
System.out.println(vehicle + "陆地运行...");
}
public void runAir(String vehicle){
System.out.println(vehicle + "空中运行...");
}
public void runWater(String vehicle){
System.out.println(vehicle + "水中运行...");
}
}
1.降低类的复杂度,一个类只负责一项职责
2.提高类的可读性,可维护性
3.降低变更引起的风险
4.通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码级违反单一职责原则;
只有类中方法的数量足够少,可以在方法级别保持单一职责原则
接口隔离原则
客户端不应该依赖他不需要的接口,即一个类对另一个类的依赖应该建立在最小接口上
package com.cedric.segregation;
// 没有使用接口隔离原则
/*
客户端不应该依赖他不需要的接口,即一个类对另一个类的依赖应该建立在最小接口上
Interface1接口对于A类和C类来说不是最小最小接口,A类和C类不需要实现多余的方法
隔离原则处理:
将接口Interface1拆分成几个独立接口,A类和C类分别与他们需要的接口建立关系,采用接口隔离原则
*/
public class SegregationDemo01 {
public static void main(String[] args) {
}
}
// Interface1接口
interface Interface1{
void operation1();
void operation2();
void operation3();
void operation4();
void operation5();
}
// 实现类B
class B implements Interface1{
@Override
public void operation1() {
System.out.println("B类 --> operation1");
}
@Override
public void operation2() {
System.out.println("B类 --> operation2");
}
@Override
public void operation3() {
System.out.println("B类 --> operation3");
}
@Override
public void operation4() {
System.out.println("B类 --> operation4");
}
@Override
public void operation5() {
System.out.println("B类 --> operation5");
}
}
// 实现类D
class D implements Interface1{
@Override
public void operation1() {
System.out.println("D类 --> operation1");
}
@Override
public void operation2() {
System.out.println("D类 --> operation2");
}
@Override
public void operation3() {
System.out.println("D类 --> operation3");
}
@Override
public void operation4() {
System.out.println("D类 --> operation4");
}
@Override
public void operation5() {
System.out.println("D类 --> operation5");
}
}
class A{ // A类通过接口Interface1 依赖(使用)B类 但是只会用到1,2,3方法
public void depend1(Interface1 i){
i.operation1();
}
public void depend2(Interface1 i){
i.operation2();
}
public void depend(Interface1 i){
i.operation3();
}
}
class C{ // B类通过接口Interface1使用D类 但是只会用到1,4,5方法
public void depend1(Interface1 i){
i.operation1();
}
public void depend4(Interface1 i){
i.operation4();
}
public void depend5(Interface1 i){
i.operation5();
}
}
package com.cedric.segregation;
/*
改进方案:
采用接口隔离原则,使用最小接口
*/
public class SegregationDemo02 {
public static void main(String[] args) {
A1 a1 = new A1();
a1.depend1(new B1()); // A类通过接口依赖B类
a1.depend2(new B1());
C1 c = new C1();
c.depend1(new D1()); // C类通过接口依赖D类
c.depend2(new D1());
}
}
interface Interface01{
void operation1();
}
interface Interface02{
void operation2();
void operation3();
}
interface Interface03{
void operation4();
void operation5();
}
class B1 implements Interface01,Interface02{
@Override
public void operation1() {
System.out.println("B1==>operation01");
}
@Override
public void operation2() {
System.out.println("B1==>operation02");
}
@Override
public void operation3() {
System.out.println("B1==>operation03");
}
}
class D1 implements Interface01,Interface03{
@Override
public void operation1() {
System.out.println("D1 ==> operation01");
}
@Override
public void operation4() {
System.out.println("D1 ==> operation04");
}
@Override
public void operation5() {
System.out.println("D1 ==> operation05");
}
}
class A1{
public void depend1(Interface01 i1){
i1.operation1();
}
public void depend2(Interface02 i2){
i2.operation2();
i2.operation3();
}
}
class C1{
public void depend1(Interface01 i1){
i1.operation1();
}
public void depend2(Interface03 i3){
i3.operation4();
i3.operation5();
}
}
依赖倒转原则
1.高层模块不用管依赖底层模块,二者都应该依赖其抽象 2.抽象不应该依赖细节,细节应该依赖抽象 3.依赖倒转的中心思想是面向接口编程 4.依赖倒转原则是基于这样的设计理念:相对于细节的多变性,抽象的东西要稳定的多, 在Java中,抽象指的是接口或者抽象类,细节就是具体的实现类 5.使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作, 把展现细节的任务交给他们的实现类去完成
package com.cedric.principle.inversion;
public class DependecyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
}
}
class Email{
public String getInfo(){
return "电子邮件信息:Hello,Cedric";
}
}
/*
完成Person接收消息的功能
方式一分析:
1.简单,比较容易想到
2.如果获取的对象是QQ、微信等,则需要新增类,同时Person也需要增加相应的接收方法
3.解决思路:引入一个抽象的接口IReceiver,表示接收者,这样Person类与接口IReceiver发生依赖
因为Email,微信等都属于接收的范围,他们各自实现IReceive接口就行,这样就符合依赖倒转原则
*/
class Person{
public void receive(Email email){
System.out.println(email.getInfo());
}
}
package com.cedric.principle.inversion.improve;
// 改进
public class DependecyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
person.receive(new WeChat());
person.receive(new QQ());
}
}
// 定义接口
interface IReceiver{
String getInfo();
}
// 电子邮件
class Email implements IReceiver{
public String getInfo(){
return "电子邮件信息:Hello,Cedric";
}
}
class QQ implements IReceiver{
@Override
public String getInfo() {
return "QQ消息:您的账号已在异地登录";
}
}
// 微信消息
class WeChat implements IReceiver{
public String getInfo(){
return "微信消息:You are so handsome";
}
}
// 方式2
class Person{
public void receive(IReceiver receiver){
System.out.println(receiver.getInfo());
}
}
依赖关系传递的三种方案和应用案例
package com.cedric.principle.inversion;
public class DependecyInversion02 {
public static void main(String[] args) {
ChangHong changHong = new ChangHong();
// 方式1
//OpenAndClose openAndClose = new OpenAndClose();
//openAndClose.open(changHong);
// 方式2 通过构造器进行依赖传递
// OpenAndClose openAndClose = new OpenAndClose(new ChangHong());
// openAndClose.open();
// 通过setter方法进行依赖传递
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.setTv(changHong);
openAndClose.open();
}
}
// 方式1:接口传递
/*
interface IOpenAndClose{ // 开关接口
void open(ITV itv);
}
interface ITV{ //ITV接口
void play();
}
// 实现接口
class OpenAndClose implements IOpenAndClose{
public void open(ITV itv){
itv.play();
}
}
*/
// 方式2:通过构造方法依赖传递
/*interface IOpenAndClose{
void open(); // 开启的抽象方法
}
interface ITV{
void play();
}
class OpenAndClose implements IOpenAndClose{
public ITV tv;
public OpenAndClose(ITV tv){
this.tv = tv;
}
public void open(){
this.tv.play();
}
}*/
// 方式3,通过setter方法传递
interface IOpenAndClose{
void open();
void setTv(ITV tv);
}
interface ITV{
void play();
}
class OpenAndClose implements IOpenAndClose{
private ITV tv;
public void setTv(ITV tv){
this.tv = tv;
}
public void open(){
this.tv.play();
}
}
class ChangHong implements ITV{
public void play(){
System.out.println("长虹电视机打开了");
}
}
依赖倒转原则需要注意的细节:
1.底层模块尽量都要有抽象类或接口,或者两者都有,程序稳定性更好
2.变量的声明类型尽量是抽象类或接口,这样我们的变量引用和实际对象间,就存在一个缓冲层,利于程序扩展和优化
3.继承时遵循里氏替换原则
里氏替换原则
OO中的继承性的思考和说明
1.继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设定规范和契约, 虽然他不强制要求所有的子类必须遵循这些契约,但是如果子类对这些已经实现的方法任意修改, 就会对整个继承体系造成破坏 2.继承在给程序设计带来便利的同时,也带来了弊端,比如使用继承会给程序带来入侵性,程序的可移植性降低, 增加对象间的耦合性,如果一个类被其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且 父类修改后,所涉及到子类的功能都有可能产生故障 3.问题提出:在编程中如何正确使用继承?=>里氏替换原则
所有引用基类的地方必须能透明的使用其子类的对象
在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类的方法
继承实际上让两个类耦合性增强了,在适当情况下,可以通过聚合,组合,依赖来解决问题
package com.cedric.principle.liskov;
// 程序误写产生的问题
public class Liskov {
public static void main(String[] args) {
A a = new A();
System.out.println(a.fun1(20, 10));
B b = new B();
System.out.println(b.fun1(20,10)); // 这里本意是求20 - 10
System.out.println(b.fun2(20,10));
}
}
class A{
// 返回两个数的差
public int fun1(int num1,int num2){
return num1 - num2;
}
}
// B继承A,新增一个功能:完成两数相加,然后和9求和
class B extends A{
// 这里重写了A类的方法,可能是无意识的
public int fun1(int a,int b){
return a + b;
}
public int fun2(int a,int b){
return fun1(a,b) + 9;
}
}
改进方案
代码实现:
package com.cedric.principle.liskov.improve;
public class Liskov {
public static void main(String[] args) {
A a = new A();
System.out.println(a.fun1(20, 10));
System.out.println("============================");
B b = new B();
// 因为B类不再继承A类,因此调用者不会再是fun1求减法
// 调用完成的功能就会很明确
System.out.println(b.fun1(20,10)); // 这里本意是求20 + 10
System.out.println(b.fun1(10,10)); //10 + 10
// 使用组合仍然可以使用到A类相关的方法
System.out.println(b.fun3(30,20)); // 本意是求出30 - 20
}
}
// 创建一个更加基础的基类
class Base{
// 把更加基础的方法和成员写到Base类
}
class A extends Base{
// 返回两个数的差
public int fun1(int num1,int num2){
return num1 - num2;
}
}
// B继承A,新增一个功能:完成两数相加,然后和9求和
class B extends Base{
private A a = new A();
// 这里重写了A类的方法,可能是无意识的
public int fun1(int a,int b){
return a + b;
}
public int fun2(int a,int b){
return fun1(a,b) + 9;
}
public int fun3(int a,int b){
return this.a.fun1(a,b);
}
}
开闭原则
1.开闭原则(Open Closed Principle)是编程中最基础、最重要的设计原则 2.一个软件实体,如类、模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方)。 用抽象构建框架,用实现扩展细节 3.当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化 4.编程中遵循其他原则,以及使用设计模式的目的就是遵循开闭原则
画图功能
代码演示:
package com.cedric.principle.ocp;
public class Ocp {
public static void main(String[] args) {
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
graphicEditor.drawShape(new Triangle());
}
}
/*
方式1优缺点:
1.优点是比较好理解,简单易操作
2.缺点是违反了设计模型的ocp原则,即对扩展开放(提供方),对修改关闭(使用方)
即当我们给类增加新功能的时候,尽量不修改代码,或者尽可能少修改代码
3.比如这是要新增一个图形种类三角形,我们需要修改的地方就非常多
*/
// 这是一个用于绘图的类
class GraphicEditor{
// 接收Shape对象,然后根据type来绘制不同的图形
public void drawShape(Shape s){
if(s.m_type == 1){
drawRectangle(s);
}else if(s.m_type == 2){
drawCircle(s);
}else if(s.m_type == 3){
// 新增修改片段
drawTriangle(s);
}
}
public void drawRectangle(Shape s){
System.out.println("绘制矩形");
}
public void drawCircle(Shape s){
System.out.println("绘制圆形");
}
// 新增修改片段
public void drawTriangle(Shape s){
System.out.println("绘制三角形");
}
}
class Shape{
int m_type;
}
class Rectangle extends Shape{
Rectangle(){
super.m_type = 1;
}
}
class Circle extends Shape{
Circle(){
super.m_type = 2;
}
}
// 增加三角形
class Triangle extends Shape{
Triangle(){
super.m_type = 3;
}
}
改进思路
把创建Shape类做成抽象类,并提供一个抽象的draw方法,让子类去实现即可
这样我们有新的图形种类时,只需要让新的图形类继承Shape,并实现draw方法即可
使用方的代码不需要修改->满足了OCP原则
package com.cedric.principle.ocp.improve;
public class Ocp {
public static void main(String[] args) {
GraphicEditor graphicEditor = new GraphicEditor();
graphicEditor.drawShape(new Rectangle());
graphicEditor.drawShape(new Circle());
graphicEditor.drawShape(new Triangle());
graphicEditor.drawShape(new Other());
}
}
// 这是一个用于绘图的类
class GraphicEditor{
// 接收Shape对象,调用draw方法
public void drawShape(Shape s){
s.draw();
}
}
// 基类
abstract class Shape{
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("绘制圆形");
}
}
// 增加三角形
class Triangle extends Shape{
@Override
public void draw() {
System.out.println("绘制三角形");
}
}
// 新增其他图形
class Other extends Shape{
public void draw(){
System.out.println("绘制其他图形");
}
}
迪米特法则
1.一个对象应该对其他对象保持最少的了解 2.类与类关系越密切,耦合度越大 3.迪米特法则(Demeter Principle)又叫最少知道原则 4.简单定义:只与直接的朋友通信
直接朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,我们就说这两个对象之间是朋友关系。耦合的方式很多,依赖、关联、组合、聚合等,其中,我们称出现成员变量,方法参数,方法返回值中的类为直接朋友.陌生的类最好不要以局部变量的方式出现在类的内部
迪米特法则注意事项和细节
1.迪米特法则的核心是降低类之间的耦合
2.但是注意:由于每个类都减少了不必要的依赖,因此迪米特法则只是要求降低类间(对象间)耦合关系,并不是要求完全没有依赖关系
有一个学校,下属有各个学院和总部,现要求打印出学校总部员工ID和学院员工ID
代码演示:
package com.cedric.principle.demeter;
import java.util.ArrayList;
import java.util.List;
// 客户端
public class Demeter01 {
public static void main(String[] args) {
// 创建了一个SchoolManager对象
SchoolManager schoolManager = new SchoolManager();
// 输出学院的员工id和学校总部的员工信息
schoolManager.printAllEmployee(new CollegeManager());
}
}
// 学校总部员工类
class Employee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}
// 学院员工类
class CollegeEmployee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}
// 管理学院员工的管理类
class CollegeManager{
// 返回学院的所有员工
public List<CollegeEmployee> getAllEmployee(){
List<CollegeEmployee> list = new ArrayList<>();
for (int i = 0; i < 10; i++) {
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id =" + i);
list.add(emp);
}
return list;
}
}
// 学校管理类
// 直接朋友:Employee、CollegeManager
// CollegeEmployee不是直接朋友,这样违背了迪米特法则
class SchoolManager{
// 返回学校总部的员工
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<>();
for (int i = 0; i < 5; i++) { // 这里增加了5个员工到list
Employee emp = new Employee();
emp.setId("学校总部的员工id=" + i);
list.add(emp);
}
return list;
}
// 该方法完成输出学校总部和学院员工信息的方法(id)
void printAllEmployee(CollegeManager sub){
/*
分析问题:
1.这里的CollegeEmployee不是SchoolManager的直接朋友
2.CollegeEmployee是以局部变量的方式出现在SchoolManager
3.违反了迪米特法则
*/
// 获取到学院员工
List<CollegeEmployee> list1 = sub.getAllEmployee();
System.out.println("================学院员工=====================");
for(CollegeEmployee employee : list1){
System.out.println(employee.getId());
}
//获取到学校总部员工
List<Employee> employees = this.getAllEmployee();
System.out.println("=================学院总部员工=================");
for(Employee employee : employees){
System.out.println(employee.getId());
}
}
}
前面设计的问题在于SchoolManager中,CollegeEmployee类并不是SchoolManager类的直接朋友 按照迪米特法则,应避免类中出现这样非直接朋友关系的耦合
按照迪米特法则改进:
package com.cedric.principle.demeter.improve;
import java.util.ArrayList;
import java.util.List;
// 客户端
public class Demeter01 {
public static void main(String[] args) {
System.out.println("------------使用迪米特法则的改进------------");
// 创建了一个SchoolManager对象
SchoolManager schoolManager = new SchoolManager();
// 输出学院的员工id和学校总部的员工信息
schoolManager.printAllEmployee(new CollegeManager());
}
}
// 学校总部员工类
class Employee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}
// 学院员工类
class CollegeEmployee{
private String id;
public void setId(String id){
this.id = id;
}
public String getId(){
return id;
}
}
// 管理学院员工的管理类
class CollegeManager{
// 返回学院的所有员工
public List<CollegeEmployee> getAllEmployee(){
List<CollegeEmployee> list = new ArrayList<>();
for (int i = 0; i < 10; i++) {
CollegeEmployee emp = new CollegeEmployee();
emp.setId("学院员工id =" + i);
list.add(emp);
}
return list;
}
// 输出员工信息
public void printEmployee(){
List<CollegeEmployee> list1 = this.getAllEmployee();
System.out.println("================学院员工=====================");
for(CollegeEmployee employee : list1){
System.out.println(employee.getId());
}
}
}
// 学校管理类
// 直接朋友:Employee、CollegeManager
// CollegeEmployee不是直接朋友,这样违背了迪米特法则
class SchoolManager{
// 返回学校总部的员工
public List<Employee> getAllEmployee(){
List<Employee> list = new ArrayList<>();
for (int i = 0; i < 5; i++) { // 这里增加了5个员工到list
Employee emp = new Employee();
emp.setId("学校总部的员工id=" + i);
list.add(emp);
}
return list;
}
// 该方法完成输出学校总部和学院员工信息的方法(id)
void printAllEmployee(CollegeManager sub){
// 将输出学院的员工方法,封装到CollegeManager
sub.printEmployee();
//获取到学校总部员工
List<Employee> employees = this.getAllEmployee();
System.out.println("=================学院总部员工=================");
for(Employee employee : employees){
System.out.println(employee.getId());
}
}
}
合成复用原则
原则是尽量使用合成/聚合的方式,而不是使用继承
设计原则的核心思想
1.找出应用中可能需要的变化之处,把他们独立出来,不要和那些不需要变化的代码混在一起 2.针对接口编程,而不是针对实现编程 3.为了交互对象之间的松耦合设计而努力
UML类图
1.用于描述系统中的类(对象)本身的组成和类(对象)之间的各种静态关系 2.类之间的关系:依赖、泛化(继承)、实现、关联、聚合与组合