设计模式的七大原则

最新推荐文章于 2024-02-19 11:30:24 发布
最新推荐文章于 2024-02-19 11:30:24 发布
阅读量658 收藏 1
点赞数
分类专栏： Java 设计模式 文章标签： 设计模式 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_38163244/article/details/111599441
版权

文章目录

设计模式的目的

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性 等多方面的挑战，设计模式是为了让程序(软件)，具有更好：

  • 代码重用性 (即：相同功能的代码，不用多次编写)
  • 可读性 (即：编程规范性, 便于其他程序员的阅读和理解)
  • 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护)
  • 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响)
  • 使程序呈现高内聚，低耦合的特性

设计模式的七大原则

  • 单一职责原则
  • 接口隔离原则
  • 依赖倒转(倒置)原则
  • 里氏替换原则
  • 开闭原则
  • 迪米特法则
  • 合成复用原则

单一职责原则

基本介绍

对类来说的，即一个类应该只负责一项职责（但是并不是说一个类中只有一个方法,一个类只负责一项工作，比如某一个类设计只用于负责订单处理，不考虑其他的）。如类 A负责两个不同职责：职责 1，职责 2。当职责 1 需求变更而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2，也就是分成两个类。

案例说明

代码演示

package rzf.qq.com.partendesign;

public class SingleResponability {
    public static void main(String[] args) {
        Vehicle v=new Vehicle();
        v.run("摩托车");
        v.run("火车");
        v.run("飞机");

    }
}
//在方式 1 的 run 方法中，违反了单一职责原则
//解决的方案非常的简单，根据交通工具运行方法不同，分解成不同类即可

class Vehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在公路上跑");
    }
}
//输出结果
摩托车在公路上跑
火车在公路上跑
飞机在公路上跑//很明显不是很符合
  • 在方式 1 的run方法中，违反了单一职责原则
  • 解决的方案非常的简单，根据交通工具运行方法不同，分解成不同类即可

改进一（类级别的单一职责）

  • 解决方式是把交通工具进行分类。
public class SingleResponability {
    public static void main(String[] args) {
        RoadVehicle v=new RoadVehicle();
        v.run("摩托车");
        v.run("火车");
        AirVehicle v1=new AirVehicle();
        v1.run("飞机");

    }
}

//1，这样做符合单一职责模式
//2,这样做开销很大，因为需要修改客户端，也就是主函数里面的内容要修改
//3，还可以对方式二进行修改

class RoadVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在公路上跑");
    }
}

class AirVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在天上飞");
    }
}
  • 这样做符合单一职责模式
  • 这样做开销很大，因为需要修改客户端，也就是主函数里面的内容要修改
  • 还可以对方式二进行修改，如下改进二

改进二（方法级别的单一职责）

public class SingleResponability {
    public static void main(String[] args) {
       Vehicle v=new Vehicle();
       v.runAir("飞机");
       v.runRoad("火车");
       v.runWater("轮船");

    }
}

class Vehicle{
    public void runRoad(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. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则（一标准情况下是要分成两个；类来分别处理）；只有类中方法数量足够少，可以在方法级别保持单一职责原则
  5. 使用单一职责模式也就是防止方法中出现很多if–else条件判断，这样的话耦合度很高。

接口隔离原则(Interface Segregation Principle)

基本介绍

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

图解

1608369574964

  • 类 A通过接口Interface1 依赖类B，类C通过接口Interface1依赖类D，如果接口Interface1 对于类 A和类 C来说不是最小接口，那么类B 和类D必须去实现他们不需要的方法。
  • 按隔离原则应当这样处理：
    • 将接口 Interface1 拆分为独立的几个接口**(这里我们拆分成 3 个接口)**，类 A 和类C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
案例说明

没有分离接口

interface interface01{
    void operation01();
    void operation02();
    void operation03();
    void operation04();
    void operation05();
}

class B implements interface01{

    @Override
    public void operation01() {
        System.out.println("class B implements operation01");
    }

    @Override
    public void operation02() {
        System.out.println("class B implements operation02");
    }

    @Override
    public void operation03() {
        System.out.println("class B implements operation03");
    }

    @Override
    public void operation04() {
        System.out.println("class B implements operation04");
    }

    @Override
    public void operation05() {
        System.out.println("class B implements operation05");
    }
}

class D implements interface01{

    @Override
    public void operation01() {
        System.out.println("class D implements operation01");
    }

    @Override
    public void operation02() {
        System.out.println("class D implements operation02");
    }

    @Override
    public void operation03() {
        System.out.println("class D implements operation03");
    }

    @Override
    public void operation04() {
        System.out.println("class D implements operation04");
    }

    @Override
    public void operation05() {
        System.out.println("class D implements operation05");
    }
}


class A{
//    A类通过接口interface01 依赖（使用）类B但是只会使用1，2，3方法
    public void depend01(interface01 i){
        i.operation01();
    }
    public void depend02(interface01 i){
        i.operation02();
    }
    public void depend03(interface01 i){
        i.operation03();
    }
}


class C{
    //    C类通过接口interface01 依赖（使用）类D但是只会使用1，4，5方法
    public void depend01(interface01 i){
        i.operation01();
    }
    public void depend04(interface01 i){
        i.operation04();
    }
    public void depend05(interface01 i){
        i.operation05();
    }
}
  • 如果不对接口进行分离，可以看到，类B,D都实现接口中的全部方法，但是真正类A,C是用不到接口中的全部方法的，所以，根据接口隔离原则，我们要对接口进行拆分。

使用接口隔离原则进行改进

  • 类 A 通过接口 Interface1 依赖类 B，类 C 通过接口Interface1 依赖类 D，如果接口 Interface1对于类 A 和类 C
  • 来说不是最小接口，那么类 B 和类 D 必须去实现他们不需要的方法
  • 将接口 Interface1 拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
  • 接口 Interface1 中出现的方法，根据实际情况拆分为三个接口

类图展示

1608370609294

代码说明

public class Segregation {
    public static void main(String[] args) {
        A a=new A();
        a.depend01(new B());//A通过接口去依赖B类
        a.depend02(new B());//A通过接口去依赖B类
        a.depend03(new B());//A通过接口去依赖B类
    }
}


interface interface01{
    void operation01();
}
interface interface02{
    void operation02();
    void operation03();
}
interface interface03{
    void operation04();
    void operation05();
}

//现在类B并不需要实现方法4,5
class B implements interface01,interface02{

    @Override
    public void operation01() {
        System.out.println("class B implements operation01");
    }

    @Override
    public void operation02() {
        System.out.println("class B implements operation02");
    }

    @Override
    public void operation03() {
        System.out.println("class B implements operation03");
    }

}

class D implements interface01,interface03{

    @Override
    public void operation01() {
        System.out.println("class D implements operation01");
    }
    @Override
    public void operation04() {
        System.out.println("class D implements operation04");
    }

    @Override
    public void operation05() {
        System.out.println("class D implements operation05");
    }
}

class A{
//    A类通过接口interface01 A类通过接口interface02依赖（使用）类B但是只会使用1，2，3方法
    public void depend01(interface01 i){
        i.operation01();
    }
    public void depend02(interface02 i){
        i.operation02();
    }
    public void depend03(interface02 i){
        i.operation03();
    }
}

class C{
    //    C类通过接口interface01 依赖（使用）类D但是只会使用1，4，5方法
    public void depend01(interface01 i){
        i.operation01();
    }
    public void depend04(interface03 i){
        i.operation04();
    }
    public void depend05(interface03 i){
        i.operation05();
    }
}

依赖倒转原则

基本介绍

依赖倒转原则(Dependence Inversion Principle)是指：

  • 高层模块不应该依赖低层模块，二者都应该依赖其抽象(抽象类或者接口，不要依赖具体的子类)
  • 抽象不应该依赖细节，细节应该依赖抽象
  • 依赖倒转(倒置)的中心思想是面向接口编程
  • 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类
  • 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成
案例说明

请编程完成 Person 接收消息 的功能。

代码说明

public class DependencyInversion {
    public static void main(String[] args) {
        Person p =new Person();
        p.receive(new Email());

    }
}


class Email{
    public String getInfo(){
        return "电子邮件信息：HELLO WORD !";
    }
}

/**
 * 方式一：
 * 优点：1 很容易想到
 * 缺点：1，如果我们要增加对短信，微信消息的接受，那么对person类也要相应增加receive()方法
 * 解决思路：引入一个抽象的接口Receiver,表示接受者，这样person就可以和接口发生依赖
 *          因为微信，email都属于接受的范畴，都实现Receiver即可，符合依赖倒转原则，
 */
class Person{
    public void receive(Email e){
        System.out.println(e.getInfo());
    }
}

使用依赖倒转原则改进

public class DependencyInversion {
    public static void main(String[] args) {
//        修改之后，客户端不需要改变
        Person p =new Person();
        p.receive(new Email());
        p.receive(new Wchat());

    }
}
interface Receiver{
//    定义一个返回消息的抽象方法
    public String getInfo();
}

class Email implements Receiver{

    @Override
    public String getInfo() {
        return "电子邮件信息:hello word !";
    }
}

//现在增加微信的消息，很容易进行扩展
class Wchat implements Receiver{
    @Override
    public String getInfo() {
        return "微信信息:hello word !";
    }
}

class Person{
    public void receive(Receiver r){
        System.out.println(r.getInfo());
    }
}
依赖关系传递的三种方式和应用案例
  1. 接口传递
  2. 构造方法传递
  3. setter方法传递

代码说明

package com.atguigu.principle.inversion.improve;

public class DependencyPass {

public static void main(String[] args) {
// TODO Auto-generated method stub ChangHong changHong = new ChangHong();
//	OpenAndClose openAndClose = new OpenAndClose();
//	openAndClose.open(changHong);

//通过构造器进行依赖传递
//	OpenAndClose openAndClose = new OpenAndClose(changHong);
//	openAndClose.open();
//通过 setter 方法进行依赖传递
OpenAndClose openAndClose = new OpenAndClose(); openAndClose.setTv(changHong); openAndClose.open();

}

}

// 方式 1： 通过接口传递实现依赖
// 开关的接口
 
// interface IOpenAndClose {
// public void open(ITV tv); //抽象方法,接收接口
// }
//
// interface ITV { //ITV 接口
// public void play();
// }
//
// class ChangHong implements ITV {
//
//	@Override
//	public void play() {
//	// TODO Auto-generated method stub
//	System.out.println("长虹电视机，打开");
//	}
//
// }
 实现接口
// class OpenAndClose implements IOpenAndClose{
// public void open(ITV tv){
// tv.play();
// }
// }

// 方式 2: 通过构造方法依赖传递
// interface IOpenAndClose {
 

// public void open(); //抽象方法
// }
// interface ITV { //ITV 接口
// public 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 {
public void open(); // 抽象方法


public void setTv(ITV tv);
}

interface ITV { // ITV 接口
public 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 {
@Override
public void play() {
// TODO Auto-generated method stub
System.out.println("长虹电视机，打开");
}
}
依赖倒转原则细节
  1. 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好，也就是说子类的上一级最好是接口或者抽象类。
  2. 变量的声明类型尽量是抽象类或接口, 这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化
  3. 继承时遵循里氏替换原则

里式替换原则

oo中继承性的思考
  • 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
  • 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性（父类的变化会影响子类），如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障
  • 问题提出：在编程中，如何正确的使用继承? => 里氏替换原则
基本介绍
  1. 里氏替换原则Liskov Substitution Principle在 1988 年，由麻省理工学院的以为姓里的女士提出的。
  2. 如果对每个类型为 T1 的对象o1，都有类型为T2的对象 o2，使得以T1定义的所有程序 P在所有的对象o1都代换成 o2时，程序P的行为没有发生变化，那么类型 T2 是类型 T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。
  3. 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法
  4. 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖 来解决问题。.
案例演示

代码说明

public class LisKvo {
    public static void main(String[] args) {
        M m=new M();
        System.out.println("11-3="+m.functionn01(11,3));
        System.out.println("1-8="+m.functionn01(1,8));
        System.out.println("********************************");
        N n=new N();
        System.out.println("11-3="+n.functionn01(11,3));//本来要计算11-3
        System.out.println("1-8="+n.functionn01(1,8));//计算1-8,但是子类对父类方法重写，结果肯定错误
    }
}


class M{
    public int functionn01(int num1,int num2){
        return num1-num2;
    }
}

class N extends M{
    @Override
    public int functionn01(int num1, int num2) {
        return num1+num2;
    }
    public int function(int num1,int num2){
        return functionn01(num1,num2)+9;
    }
}

解决方法

  • 我们发现原来运行正常的相减功能发生了错误。原因就是类 B 无意中重写了父类的方法，造成原有功能出现错误。在实际编程中，我们常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候
  • 通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等关系代替.

改进方案

1608441452055

代码改进

public class LisKvo {
    public static void main(String[] args) {
        M m=new M();
        System.out.println("11-3="+m.functionn01(11,3));
        System.out.println("1-8="+m.functionn01(1,8));
        System.out.println("********************************");
        N n=new N();
//        因为N不在继承m，那么调用者不会再认为function01()是做减法的
        int num=n.function02(11,3);
        System.out.println("11+3="+num);
        System.out.println("1+8="+n.function02(1,8));
//        现在使用组合的方式还可以做减法
        System.out.println(n.function04(11,3));//8
    }
}

class Base{
//    吧更加基础的方法和属性写到基础类中

}

class M extends Base{
    public int functionn01(int num1,int num2){
        return num1-num2;
    }
}

class N extends Base{
//    如果N类要使用M类，就使用一个组合的关系
    private M m=new M();//形成组合关系
//    加入我们想使用M的方法,就用下面的操作
    public int function02(int num1,int num2){
        return num1+num2;
    }
    public int function03(int num1,int num2){
        return function02(num1,num2)+9;
    }
    public int function04(int num1,int num2){
        return m.functionn01(num1,num2);
    }
}

开闭原则

基本介绍
  • 开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
  • 一个软件实体如类，模块和函数应该对扩展开放**(对提供方,增加功能)**，对修改关闭(对使用方不需要修改)。用抽象构建框架，用实现扩展细节。
  • 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
  • 编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
  1.  编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
案例说明

1608443054162

代码说明

public class OcpDemo {
    public static void main(String[] args) {
        GraphicEditor g=new GraphicEditor();
        g.drawShape(new Rectangle());
        g.drawShape(new Circle());

    }
}


//这是一个用于绘图的类 [使用方]
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 r) {
        System.out.println(" 绘制矩形 ");
    }

    //绘制圆形
    public void drawCircle(Shape r) {


        System.out.println(" 绘制圆形 ");
    }

    //绘制三角形
    public void drawTriangle(Shape r) {
        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;
    }
}


//新增画三角形
class Triangle extends Shape {
    Triangle() {
        super.m_type = 3;
    }
}
  1. 优点是比较好理解，简单易操作。
  2. 缺点是违反了设计模式的ocp 原则，即对扩展开放(提供方)，对修改关闭(使用方)。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.
  3. 比如我们这时要新增加一个图形种类 三角形，我们需要做如下修改，修改的地方较多,需要修改使用方。
改进思路

思路：把创建 Shape 类做成抽象类，并提供一个抽象的 draw 方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承 Shape，并实现draw方法即可，使用方的代码就不需要修 -> 满足了开闭原则

代码实现

public class OcpDemo {
    public static void main(String[] args) {
        GraphicEditor g=new GraphicEditor();
        g.drawShape(new Rectangle());
        g.drawShape(new Circle());
        g.drawShape(new Triangle());
        g.drawShape(new Other());
    }
}


//这是一个用于绘图的类 [使用方]
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 {
    Rectangle() {
        super.m_type = 1;
    }

    @Override
    public void draw() {
        System.out.println("绘制矩形");
    }
}


class Circle extends Shape {
    Circle() {
        super.m_type = 2;
    }

    @Override
    public void draw() {
        System.out.println("绘制圆形");
    }
}


//新增画三角形
class Triangle extends Shape {
    Triangle() {
        super.m_type = 3;
    }

    @Override
    public void draw() {
        System.out.println("绘制三角形");
    }
}

class Other extends Shape{

    @Override
    public void draw() {
        System.out.println("绘制其他图形");
    }
}
  • 经过上面的设计，我们在需要绘制其他图形时候，只需要继承shape然后实现方法即可，再使用方不需要修改代码。

迪米特法则

基本介绍
  1. 一个对象应该对其他对象保持最少的了解（这样耦合度比较低）
  2. 类与类关系越密切，耦合度越大
  3. 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息
  4. 迪米特法则还有个更简单的定义：只与直接的朋友通信
  5. 直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
应用案例

有一个学校，下属有各个学院和总部，现要求打印出学校总部员工 ID 和学院员工的 id

代码说明

public class Demeter {
    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<CollegeEmployee>();
        for (int i = 0; i < 10; i++) { //这里我们增加了 10 个员工到 list
            CollegeEmployee emp = new CollegeEmployee();
            emp.setId("学院员工 id= " + i);
            list.add(emp);
        }
        return list;


    }
}

//学校管理类

//分析 SchoolManager 类的直接朋友类有哪些 Employee、CollegeManager
//CollegeEmployee 不是 直接朋友 而是一个陌生类，这样违背了 迪米特法则
class SchoolManager {
    //返回学校总部的员工
    public List<Employee> getAllEmployee() {
        List<Employee> list = new ArrayList<Employee>();

        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 e : list1) {
            System.out.println(e.getId());
        }

        //获取到学校总部员工
        List<Employee> list2 = this.getAllEmployee();
        System.out.println("------------学校总部员工------------");
        for (Employee e : list2) {
            System.out.println(e.getId());
        }
    }
}
  • 前面设计的问题在于 SchoolManager中，CollegeEmployee 类并不是 SchoolManager 类的直接朋友 (分析)
  • 按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合

代码改进

public class Demeter {
    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<CollegeEmployee>();
        for (int i = 0; i < 10; i++) { //这里我们增加了 10 个员工到 list
            CollegeEmployee emp = new CollegeEmployee();
            emp.setId("学院员工 id= " + i);
            list.add(emp);
        }
        return list;
    }
  //封装的过程，对外只提供接口
    public void printEmployee(){
//        解决方法：
//        1 将输出学院员工的方法封装到CollegeManager类里面
        List<CollegeEmployee> list1 = this.getAllEmployee();
        System.out.println("------------学院员工------------");
        for (
                CollegeEmployee e : list1) {
            System.out.println(e.getId());
        }
    }
}

//学校管理类

//分析 SchoolManager 类的直接朋友类有哪些 Employee、CollegeManager
//CollegeEmployee 不是 直接朋友 而是一个陌生类，这样违背了 迪米特法则
class SchoolManager {
    //返回学校总部的员工
    public List<Employee> getAllEmployee() {
        List<Employee> list = new ArrayList<Employee>();

        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) {
        sub.printEmployee();//对过程进行封装
        //获取到学校总部员工
        List<Employee> list2 = this.getAllEmployee();
        System.out.println("------------学校总部员工------------");
        for (Employee e : list2) {
            System.out.println(e.getId());
        }
    }
}
迪米特法则细节
  • 迪米特法则的核心是降低类之间的耦合
  • 但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系， 并不是要求完全没有依赖关系

合成复用原则（Composite Reuse Principle）

基本介绍

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

1608446753839

类B想使用类A中的方法，如果通过继承的方式，那么耦合度会很高，通过聚合的方式，可以降低耦合度，有三种方式，第一种是作为函数的参数传递，调用A的方法，第二种是作为属性存在，调用A的方法，第三种是使用Set()方法。

欢迎关注作者个人公众号，专注分享java，大数据，python，JVM,数据结构及计算机基础知识。

在这里插入图片描述

bugcode.online
关注
专栏目录
Java设计模式七大原则-单一职责原则.md
08-13
设计模式
Java设计模式七大原则-合成聚合复用原则.md
最新发布
08-13
java八股文
设计模式 | 学习笔记 | 设计模式七大原则
Ashmore的博客
09-15 150
设计模式的目的 代码重用性 (即：相同功能的代码，不用多次编写) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响) 使程序呈现高内聚，低耦合的特性 单一职责原则 对类来说的，即一个类应该只负责一项职责。 案例 方案1 package com.atguigu.principle.singleresponsibility; public class SingleRespons
设计模式七大原则之单一职责原则
qq784515681的博客
03-26 605
一、设计模式的目的： 编写软件过程中，程序员面临来自耦合性，内聚性，可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)，具有更好的： 代码重用性 (即:相同功能的代码，不用多次编写) 可读性 (即:编程规范性, 便于其他程序员的阅读和理解) 可扩展性 (即:当需要增加新的功能时，非常的方便，称为可维护) 可靠性 (即:当我们增加...
设计模式（2）-设计模式的七大原则（二）
九岁ya的博客
03-27 189
4.里氏替换原则 基本介绍 里氏替换原则(Liskov Substitution Principle)在1988年，由麻省理工学院的以为姓里 的女士提出的。 如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序 P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1 的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。 ...
详细介绍设计模式七大原则
m0_54187478的博客
02-19 2574
单一职责原则：一个类应该只有一个引起它变化的原因。开闭原则：软件实体应对扩展开放，对修改封闭。里氏替换原则：子类型必须能够替换掉它们的基类型。依赖倒置原则：高层模块不应依赖于低层模块，两者都应依赖于抽象；抽象不应依赖于细节，细节应依赖于抽象。接口隔离原则：使用多个专门的接口比使用单一的总接口更好。合成/聚合复用原则：尽量使用对象的组合/聚合，而不是继承关系达到复用的目的。迪米特法则（最少知道原则）：一个对象应对其他对象有尽可能少的了解。
设计模式七大原则
java123456111的博客
05-18 4617
1、设计模式的目的 ​ 编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性 等多方面的挑战，设计模式是为了让程序(软件)，具有更好 ​ 1) 代码重用性 (即：相同功能的代码，不用多次编写) ​ 2) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解) ​ 3) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护) ​ 4) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响) ​ 5) 使程序呈现高内聚，低耦合的特性 2、设计模式七大原则 ​ 设计模
设计模式七大原则（案例解析）
Android系统优化
11-25 4256
一、 设计模式的目的 编写软件过程中，程序员面临着来自 耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性 等多方面的挑战，设计模式是为了让程序(软件)，具有更好 1) 代码重用性 (即：相同功能的代码，不用多次编写) 2) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解) 3) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护) 4) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响) 5) 使程序呈现高内聚，低耦合的特性 二. 设计模式七大原则 ...
设计模式——七大设计原则
weixin_43412762的博客
12-05 3061
设计模式的七大原则：开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则、迪米特法则
设计模式七大原则——开闭原则
★★光亭★★
02-06 1万+
设计模式七大原则——开闭原则
Java设计模式之七大设计原则
qq_49529322的博客
04-28 1万+
Java设计模式之七大设计原则 本文对Java设计模式中的七大设计原则进行汇总介绍，提炼最核心的概念。 设计模式总结笔记 一、设计模式七大原则 设计模式的目的： 代码可重用性：相同功能的代码，不用多次编写。 可读性：编程规范性，便于其他程序员的阅读和理解。 可扩展性：当需要增加新的功能的时候，非常方便，称为可扩展性。 可靠性：当我们新增功能后，对原来的功能没有影响。 使程序呈现高内聚、低耦合特性。 1.1、单一职责原则 不遵守单一职责原则： 对类来说的，就是一个类应该只负责一项职责。 比如：Us
设计模式七大原则——迪米特原则
★★光亭★★
02-06 8913
设计模式七大原则——迪米特原则
yoyiyi#SoleilNotes#001.设计模式七大原则1
07-25
2.1 单一职责原则 2.2 接口隔离原则 2.3 依赖倒置原则 2.4 里式替换原则 2.5 开闭原则 2.6 迪米特原则 2.7 合成复用原则
Jvm系列-Jvm概述（一）
热门推荐
理科男同学
11-07 5万+
目录 1，什么是JVM？ 2，JVM跨平台及原理 3，JVM的分类 4，JVM的位置 5，JVM的体系结构 6，Java代码的执行流程 7，JVM的架构模型 8，JVM的生命周期 9，三大商业虚拟机 1，什么是JVM？ JVM 是 java虚拟机，是用来执行java字节码(二进制的形式)的虚拟计算机。 jvm是运行在操作系统之上的，与硬件没有任何关系。 2，JVM跨平台及原理 跨平台：由Java编写的程序可以在不同的操作系统上运行：一次编写，多处运行。 原理：编译之后的字节码
数据结构-二叉排序树（BST树）
理科男同学
11-15 9979
1，二叉排序树介绍 二叉排序树（Binary Sort Tree）或者是一颗空树；或者是具有如下性质的二叉树： 若它的左子树不空，则左子树上所有结点的值均小于它的根结点的值； 若它的右子树不空，则右子树上所有结点的值均大于它的根结点的值； 它的左、右子树又分别为二叉排序树。 显然二叉排序树的定义是一个递归形式的定义，所以后面景禹要讲的插入、查找和删除都是基于递归的形式。特别说明：如果有相同的值，可以将该节点放在左子节点或右子节点 1.1，二叉排序树的构建 假设我们有初始的无序...
数据结构-平衡二叉树(AVL树)
理科男同学
11-15 2775
目录 1，平衡二叉树的介绍 1.1，二叉排序树存在的问题 1.2，平衡二叉树 1.3，平衡二叉树的创建 1.4，平衡二叉树的查找 2，代码实现 2.1，平衡二叉树的节点类型 2.2，LL旋转（单右旋转） 2.3，RR旋转（单左旋转） 2.4，向avl树中添加一个节点 2.5，求左右子树的高度 2.6，求平衡二叉树的高度 2.7，中序遍历二叉树 2.8，创建一颗平衡二叉树 3，测试代码 1，平衡二叉树的介绍 1.1，二叉排序树存在的问题 在介绍平衡二叉树之前，我们先来看看.
数据结构-（2-3树，2-3-4树，B-树，B+树）
理科男同学
11-16 2154
目录 1，二叉树存在问题分析 2，多叉树B树的介绍 2.1，2-3树和2-3-4树的介绍 2.2，B树的查找 2.3，B树的创建和插入 2.4，B树的删除 3，B+树 3.1，m 阶的B+树与m阶的B树的主要差异 1，二叉树存在问题分析 虽然我们说二叉排序树，平衡二叉树的查找操作效率较高，但是也存在问题, 请看下面的二叉树。 二叉树需要加载到内存的，如果二叉树的节点少，没有什么问题，但是如果二叉树的节点很多(比如1亿)， 就存在如下问题: 问题1：在构建二叉树时，需要多次进行i/
数据结构-选择排序（简单选择排序，堆排序）
理科男同学
12-09 2082
目录 1，简单选择排序 1.1，简单选择排序思想 1.2，选择排序的时间复杂度分析 1.3，简单选择排序代码实现 2，堆排序 2.1，什么是堆排序 2.2，堆排序的思想 2.3，堆排序时间复杂度分析 2.4，代码实现 1，简单选择排序 1.1，简单选择排序思想 选择排序(Selection sort)是一种简单直观的排序算法。 简单选择排序算法的比较次数和初始的序列排列顺序无关。 它的基本思想是：首先在未排序的数列中找到最小(or最大)元素，然后将其存放到数列的起始位置；接着，.
JVM系列-String-Table的理解
理科男同学
12-14 1329
1，String的基本特性 String：字符串，使用一对 “” 引起来表示 String s1 = "hello" ; //字面量的定义方式 String s2 = new String("hello"); // new 对象的方式 String被声明为final的，不可被继承，如果字符串需要跨进程传输，是可以的，应为String实现了序列化接口。 String实现了Serializable接口：表示字符串是支持序列化的。实现了Comparable接口：表示Strin
java 设计模式 七大原则
09-14
Java设计模式的七大原则包括： 1) 单一职责原则：一个类应该只有一个引起变化的原因，即一个类应该只有一个职责。 2) 接口隔离原则：客户端不应该依赖它不需要的接口。应该将接口细分为更小的接口，以便于客户端只...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值