设计模式学习心得之前置知识 UML图看法与六大原则(上)

简介: 设计模式学习心得之前置知识 UML图看法与六大原则(上)

你好,我是Qiuner. 为记录自己编程学习过程和帮助别人少走弯路而写博客

这是我的 github https://github.com/Qiuner ⭐️

gitee https://gitee.com/Qiuner 🌹

如果本篇文章帮到了你 不妨点个吧~ 我会很高兴的 😄 (^ ~ ^)

想看更多 那就点个关注吧 我会尽力带来有趣的内容 😎

设计模式学习心得 前置知识

UML图

统一建模语言(Unified Modeling Language,UML)是用来设计软件的可视化建模语言。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。

UML 从目标系统的不同角度出发,定义了用例图、类图、对象图、状态图、活动图、时序图、协作图、构件图、部署图等 9 种图。

类图如何看

  • 有三个属性 name为公共 类型是string、age为受保护 类型是int 默认值为18、sexNumber 为私有类型是int
  • 有两个私有方法,方法eat 有两个参数 返回值是void,方法sleep 有一个参数 返回值是void

属性/方法名称前加的加号和减号表示了这个属性/方法的可见性,UML类图中表示可见性的符号有三种:

  • +:表示public
  • -:表示private
  • #:表示protected

属性的完整表示方式是: 可见性 名称 :类型 [ = 缺省值]

方法的完整表示方式是: 可见性 名称(参数列表) [ : 返回类型]

注意:

1,中括号中的内容表示是可选的

类图关系表示

关联关系

关联关系指的是类与类之间的关系,有三种。分别为单向关联,双向关联,自关联。

1,单向关联

在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址,这通过让Customer类持有一个类型为Address的成员变量类实现。

  • 单向关联是一种弱依赖关系,通常表示一个对象知道另一个对象的存在,但被引用的对象并不知道哪些对象引用了它。
  • 在单向关联中,一个类(或对象)可以引用另一个类(或对象),但被引用的类(或对象)不引用回来。这种关系常常体现在类之间的成员变量或方法参数中。
  • 生命周期管理方面,被引用的对象不受引用它的对象的影响。即使引用它的对象被销毁,被引用的对象仍然可以存在。
2,双向关联

从上图中我们很容易看出,所谓的双向关联就是双方各自持有对方类型的成员变量。

在UML类图中,双向关联用一个不带箭头的直线表示。上图中在Customer类中维护一个List,表示一个顾客可以购买多个商品;在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。

3,自关联

自关联在UML类图中用一个带有箭头且指向自身的线表示。上图的意思就是Node类包含类型为Node的成员变量,也就是“自己包含自己”。

聚合关系

聚合关系是关联关系的一种,是强关联关系,是整体和部分之间的关系。

聚合关系也是通过成员对象来实现的,其中成员对象是整体对象的一部分,但是成员对象可以脱离整体对象而独立存在。例如,学校与老师的关系,学校包含老师,但如果学校停办了,老师依然存在。

在 UML 类图中,聚合关系可以用带空心菱形的实线来表示,菱形指向整体。下图所示是大学和教师的关系图:

  • 聚合关系表示的是一种强关联,它表示整体与部分之间的关系。在聚合关系中,整体对象拥有部分对象,但部分对象不是整体对象的一部分。
总结单项关联、与聚合关系

单向关联是一种较为弱的关系,通常用于表示简单的引用关系;而聚合关系是一种更强的关系,用于表示整体与部分之间的包含关系,聚合关系的依赖是双向的。

  • 单项、聚合关联是手拿工具,组合是工具长你身上
  • 目前看来单项是拿只能解决某个的工具,和聚合是拿通用的工具
组合关系

组合表示类之间的整体与部分的关系,但它是一种更强烈的聚合关系。

在组合关系中,整体对象可以控制部分对象的生命周期,一旦整体对象不存在,部分对象也将不存在,部分对象不能脱离整体对象而存在。例如,头和嘴的关系,没有了头,嘴也就不存在了。

在 UML 类图中,组合关系用带实心菱形的实线来表示,菱形指向整体。下图所示是头和嘴的关系图:

依赖关系

依赖关系是一种使用关系,它是对象之间耦合度最弱的一种关联方式,是临时性的关联。在代码中,某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类(被依赖类)中的某些方法来完成一些职责。

在 UML 类图中,依赖关系使用带箭头的虚线来表示,箭头从使用类指向被依赖的类。下图所示是司机和汽车的关系图,司机驾驶汽车:

  • car和driver是依赖关系,driver运行要用car
继承关系(泛化关系)

继承关系是对象之间耦合度最大的一种关系,表示一般与特殊的关系,是父类与子类之间的关系,是一种继承关系。

在 UML 类图中,泛化关系用带空心三角箭头的实线来表示,箭头从子类指向父类。在代码实现时,使用面向对象的继承机制来实现泛化关系。例如,Student 类和 Teacher 类都是 Person 类的子类,其类图如下图所示:

实现关系

实现关系是接口与实现类之间的关系。在这种关系中,类实现了接口,类中的操作实现了接口中所声明的所有的抽象操作。

在 UML 类图中,实现关系使用带空心三角箭头的虚线来表示,箭头从实现类指向接口。例如,汽车和船实现了交通工具

软件设计原则

我的项目结构

开闭原则

对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。简言之,是为了使程序的扩展性好,易于维护和升级。

想要达到这样的效果,我们需要使用接口和抽象类。

因为抽象灵活性好,适应性广,只要抽象的合理,可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展,当软件需要发生变化时,只需要根据需求重新派生一个实现类来扩展就可以了。

下面以 搜狗输入法 的皮肤为例介绍开闭原则的应用。

【例】搜狗输入法 的皮肤设计。

分析:搜狗输入法 的皮肤是输入法背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的输入法的皮肤,也可以从网上下载新的皮肤。这些皮肤有共同的特点,可以为其定义一个抽象类(AbstractSkin),而每个具体的皮肤(DefaultSpecificSkin和HeimaSpecificSkin)是其子类。用户窗体可以根据需要选择或者增加新的主题,而不需要修改原代码,所以它是满足开闭原则的。

感悟与代码
  • 这里SouGouInput的关系线画错了 应该是聚合关系
  • 开闭原则的关键是 继承关系、组合关系
  • 开闭原则就类似汽车换轮子 可以换不同厂家的一个型号的轮子。将具体的轮子交给别人来换,装轮子的铁圈却不会改变
package com.priniciples.openingAndClosing;
public abstract class AbstractSkin {
    /**
     *默认皮肤类
     */
    public void display() {
    }
}
package com.priniciples.openingAndClosing;
// 这个是和AbstractSkin是聚合关系
//
public class SougouInput {
    private  AbstractSkin skin;
    public void setSkin(AbstractSkin skin){
        this.skin=skin;
    }
    public void display() {
        skin.display();
    }
}

客户端

package com.priniciples.openingAndClosing;
public class Client {
    public static void main(String[] args) {
        // 搜狗输入发对象
        SougouInput input = new SougouInput();
        // 用户1的皮肤对象
        User1Skin user1Skin = new User1Skin();
        // 用户2的皮肤对象
        User2Skin user2Skin = new User2Skin();
    //    当我们要显示使用皮肤的时候,只要调用搜狗输入法对象的方法
    //    使用用户一的输入法对象
        input.setSkin(user1Skin);
        //显示用户一皮肤
        input.display();
        System.out.printf("接下来是用户2的皮肤\n");
    //     显示用户2的皮肤
        input.setSkin(user2Skin);
        input.display();
    }
}

具体的橡胶轮子

package com.priniciples.openingAndClosing;
// 用户一的皮肤
public class User1Skin  extends  AbstractSkin{
    public void display(){
        System.out.printf("我是用户1的皮肤\n");
    }
}
package com.priniciples.openingAndClosing;
// 用户2的皮肤
public class User2Skin extends  AbstractSkin{
    public void display(){
        System.out.printf("我是用户2的皮肤\n");
    }
}

里氏代换原则

里氏代换原则是面向对象设计的基本原则之一。

里氏代换原则:任何基类可以出现的地方,子类一定可以出现。通俗理解:子类可以扩展父类的功能,但不能改变父类原有的功能。换句话说,子类继承父类时,除添加新的方法完成新增功能外,尽量不要重写父类的方法。

如果通过重写父类的方法来完成新的功能,这样写起来虽然简单,但是整个继承体系的可复用性会比较差,特别是运用多态比较频繁时,程序运行出错的概率会非常大。

下面看一个里氏替换原则中经典的一个例子

【例】正方形不是长方形。

在数学领域里,正方形毫无疑问是长方形,它是一个长宽相等的长方形。所以,我们开发的一个与几何图形相关的软件系统,就可以顺理成章的让正方形继承自长方形。

代码如下:

长方形类(Rectangle):

public class Rectangle {
    private double length;
    private double width;
    public double getLength() {
        return length;
    }
    public void setLength(double length) {
        this.length = length;
    }
    public double getWidth() {
        return width;
    }
    public void setWidth(double width) {
        this.width = width;
    }
}

正方形(Square):

由于正方形的长和宽相同,所以在方法setLength和setWidth中,对长度和宽度都需要赋相同值。

public class Square extends Rectangle {
    
    public void setWidth(double width) {
        super.setLength(width);
        super.setWidth(width);
    }
    public void setLength(double length) {
        super.setLength(length);
        super.setWidth(length);
    }
}

类RectangleDemo是我们的软件系统中的一个组件,它有一个resize方法依赖基类Rectangle,resize方法是RectandleDemo类中的一个方法,用来实现宽度逐渐增长的效果。

public class RectangleDemo {
    
    public static void resize(Rectangle rectangle) {
        while (rectangle.getWidth() <= rectangle.getLength()) {
            rectangle.setWidth(rectangle.getWidth() + 1);
        }
    }
    //打印长方形的长和宽
    public static void printLengthAndWidth(Rectangle rectangle) {
        System.out.println(rectangle.getLength());
        System.out.println(rectangle.getWidth());
    }
    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle();
        rectangle.setLength(20);
        rectangle.setWidth(10);
        resize(rectangle);
        printLengthAndWidth(rectangle);
        System.out.println("============");
        Rectangle rectangle1 = new Square();
        rectangle1.setLength(10);
        resize(rectangle1);
        printLengthAndWidth(rectangle1);
    }
}

我们运行一下这段代码就会发现,假如我们把一个普通长方形作为参数传入resize方法,就会看到长方形宽度逐渐增长的效果,当宽度大于长度,代码就会停止,这种行为的结果符合我们的预期;假如我们再把一个正方形作为参数传入resize方法后,就会看到正方形的宽度和长度都在不断增长,代码会一直运行下去,直至系统产生溢出错误。所以,普通的长方形是适合这段代码的,正方形不适合。

我们得出结论:在resize方法中,Rectangle类型的参数是不能被Square类型的参数所代替,如果进行了替换就得不到预期结果。因此,Square类和Rectangle类之间的继承关系违反了里氏代换原则,它们之间的继承关系不成立,正方形不是长方形。

如何改进呢?此时我们需要重新设计他们之间的关系。抽象出来一个四边形接口(Quadrilateral),让Rectangle类和Square类实现Quadrilateral接口

感悟与代码
package com.priniciples.richterSubstitution.after;
/**
 * @Description
 * @Author Qiu
 * @Date 2024/4/19
 */
public interface Quadrilateral {
    // 获取长
    double getLength();
    // 获取宽
    double getWidth();
}
  • 这里将四边形作为长方形和正方形的父类
  • 上面将长方形作为正方形的父类 其核心是认为正方形是短边长方形
  • 这里实现的关键 就是正方形的getLength、getWidth都是返回side,虽然正方形宽高都是side,但是为了满足里氏原则的子类可以无感替换父类,因此如此
  • 这个例子不如开闭原则一样直观,核心就是 子类保留父类功能下进行自身功能扩展
  • 里氏原则 是 实现关系,但这个原则重点不是几种关系组合


设计模式学习心得之前置知识 UML图看法与六大原则(下):https://developer.aliyun.com/article/1548555

目录
相关文章
|
2天前
|
设计模式 Java 程序员
【23种设计模式·全精解析 | 概述篇】设计模式概述、UML图、软件设计原则
本系列文章聚焦于面向对象软件设计中的设计模式,旨在帮助开发人员掌握23种经典设计模式及其应用。内容分为三大部分:第一部分介绍设计模式的概念、UML图和软件设计原则;第二部分详细讲解创建型、结构型和行为型模式,并配以代码示例;第三部分通过自定义Spring的IOC功能综合案例,展示如何将常用设计模式应用于实际项目中。通过学习这些内容,读者可以提升编程能力,提高代码的可维护性和复用性。
【23种设计模式·全精解析 | 概述篇】设计模式概述、UML图、软件设计原则
|
4月前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
4月前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
3月前
|
设计模式 Java 关系型数据库
设计模式——设计模式简介和七大原则
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
|
3月前
|
设计模式 Java 测试技术
Java设计模式-UML与设计原则(1)
Java设计模式-UML与设计原则(1)
|
4月前
|
设计模式 uml
设计模式常用的UML图------类图
这篇文章介绍了UML中类图的基本概念和用途,详细解释了类与接口、类之间的关系,包括继承、实现、组合、聚合、关联和依赖等六种关系,并展示了它们在类图中的表示方法。
设计模式常用的UML图------类图
|
4月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
4月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
|
4月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
React开发设计模式及原则概念问题之什么是设计模式,单一职责原则如何理解
|
6月前
|
设计模式 uml
设计模式学习心得之前置知识 UML图看法与六大原则(下)
设计模式学习心得之前置知识 UML图看法与六大原则(下)
48 2