系统架构设计——学习篇之类的设计(UML)

11 篇文章 1 订阅
7 篇文章 0 订阅

概述

“编程是一门技术,更加是一门艺术,不能只满足于写完代码运行结果正确久完事,时常考虑如何让代码更加简练,更加容易维护,容易扩展和服用,只有这样才可以真正得到提高。写出优雅的代码真的是一种很爽的事情。UML类图也不是一学就会的,需要有一个慢慢熟练的过程。所谓学无止境,其实这(类的设计)才是理解面向对象的开始。” ——大话设计模式

对于初学者来说,我们不仅仅是要学会面向对象的封装、继承和多态,我们更应该在理解的基础上把这些思想运用到我们的编码当中。在我学习过JAVA过后的很长一段时间,很少真正思考过,类与类之间除了继承、实现和隶属(包含)的关系还有哪些。而当我碰到问题的时候再去思考如何更改类的设计。所以在我们开始整个项目之前,我们应该尽可能的想好每一个类该如何去设计,类与类该如何处理他们的关系,这样我们再进行模式和业务设计的时候才不至于遇到问题了再重新思考。这也是实现代码复用,实现高内聚低耦合的必要条件。

下面我们从UML的类图出发,学习一下类的设计

1. 类(class)

在我看来,类可以看做面向对象程序设计的单位,是封装、继承和多态的最小元素。在面向对象的思想中,一切万物皆对象。
在UML中类图分三层,第一层显示类的名称,如果是抽象类,则就用斜体显示。第二层是类的特性,通常就是字段和属性。第三层是类的操作,通常是方法和行为。
其中,“+”表示public,“-”表示private,“#”表示protected。
这里写图片描述

2. 继承(extend)

这是面向对象程序设计的三大特性之一。在UML中使用三角形和实线来表示的。
这里写图片描述
代码表示为

public class Bird extend Animal
{
    ...
}

3. 实现(implements)

Java接口是一系列方法的声明,是一些方法特征的集合,一个接口只有方法的特征没有方法的实现,因此这些方法可以在不同的地方被不同的类实现,而这些实现可以具有不同的行为(功能)。
这里写图片描述
代码表示为

public class Bird extend Animal implements Flyable
{
    public void fly(){
        ...
    }
}
public interface Flyable
{
    public abstract void fly();
}

4. 依赖(Dependency)

依赖可以按照必要条件来理解,简单地理解就是依存的关系,但不是相互依存。一般此关系表示在构造方法中,以参数的形式传入。这就表达了如果没有参数,那么也就无从构造的依存关系。
这里写图片描述
代码表示为

public class Animal
{
    private Oxygen oxygen = null;
    private Water water = null;
    public Animal(Oxygen o,Water w){
        this.oxygen = o;
        this.water = w;
    }
}

5. 组合(Composition)

组合关系也是一种强的”拥有”关系,与依赖不同的是,组合中的组件是可以是由自身创建的。按前面的例子来说,依赖关系的两者其实是独立产生的,只是一方的存在依赖于另一方。而组合中的双方,是一方拥有另一方,体现了严格的部分和整体的关系,部分和整体的生命周期一致
这里写图片描述
代码表示为

public class Bird
{
    private Wing wing;
    public Bird(){
        wing = new Wing();
    }
}
public class Wing
{
    ...
}

6. 聚合(Aggregation)

聚合表示一种弱的“拥有”关系,体现的是A对象可以包含B对象,但B对象不是A对象的一部分。相比于上面的组成关系,区别在于组成关系的组件的生命周期与整体是相同的,如果鸟死了,那么他的翅膀也就不能用了(如果你认为死去鸟的翅膀还可以移植到别的鸟身上继续使用,那么鸟和翅膀其实就是聚合关系,具体的解释稍后再说)。而聚合关系中的整体和部分是相对弱化的,就像鸟群是有鸟组成的,如果没有鸟群,鸟还是鸟
这里写图片描述
代码表示为

public class Bery
{
    private Bird[] arrayBirds;
    public abstract void SouthwardMigration();
    ...
}

7. 关联(Association)

类与类之间的联接,它使一个类知道另一个类的属性和方法。例如如果A依赖于B,则B体现为A的全局变量。关联关系有双向关联和单向关联。双向关联:两个类都知道另一个类的公共属性和操作。单向关联:只有一个类知道另外一个类的公共属性和操作。大多数关联应该是单向的,单向关系更容易建立和维护,有助于寻找可服用的类。关联关系在所有的关系中属于最弱的关系。
这里写图片描述
代码表示为

public class Bird
{
    private Climate climate;
}
public class Climate
{
    private String season;
    ...
}

8. 关联、聚合、组合、依赖之间的关系

他们各自的定义之前都说过了,这里只是想说一个问题,就是四者的关系其实都是相对的,这里拿男女关系做一个比喻,相比大家能更好的理解:

  1. 男女关系最开始的时候,双方刚刚认识,这时候要么男方对女方有意思,要么女方对男方有意思,再或者双方都有好感,那么双方的关系就是关联关系,只是单纯的把对方留意一下。这就是关联关系,只是一方知道另一方。
  2. 通常来说,我们的异性朋友不止一个,即便是男方对女方有意思,女方也是男方众多异性朋友中的一个,女方亦然。这些异性朋友其实就是一个聚合。所以,如果站在女方的角度,她和男方是关联的关系,如果站在异性朋友的角度,女方只是男方的异性朋友之一,女方和异性朋友就是聚合关系。这也就说明了,关系其实都是相对的。
  3. 接下来,双方结果相恋、相爱,最后走入婚姻的殿堂,组成了他们的家庭。这时候站在家庭的角度,他们和家庭之间就是一种组合关系。值得注意的是,如果家庭破裂了,丈夫和妻子的角色也就不存在了。严格体现了整体和部分的关系,生命周期是一样的。
  4. 家庭的维持是需要收入来源的,一般来说,男方是这个家庭的顶梁柱,那么家庭相对于男方的关系就是依赖关系。而家庭破裂了,男方一样有经济来源,所以二者的生命周期是不一样的。

至此,我们就要进入下一阶段的学习了——设计模式。


注意:转载请标明,转自itboy-木小草
尊重原创,尊重技术。

  • 7
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
电子商务系统是现代商业的重要组成部分,大厂应用场景之一,可以通过使用UML(统一建模语言)来进行建模设计。下面是一个电商系统建模设计教程的例子: 首先,我们需要确定系统的角色。在电商系统中,常见的角色有买家、卖家和管理员。买家是购买商品的用户,卖家是出售商品的商家,而管理员则负责管理和维护系统。 接下来,我们可以使用用例图来表示系统的功能。如买家可以浏览商品、添加商品到购物车、下订单等。卖家可以添加商品、管理订单等。管理员可以管理用户和商品信息。 然后,我们可以使用类图来表示系统中的实体。如用户类、商品类和订单类。用户类中包括买家和卖家的属性和操作。商品类包括商品的名称、描述和价格等属性。订单类包括订单的状态、数量和总价等属性。 接下来,我们可以使用对象图来表示系统中的具体对象和关系。如买家对象可以和商品对象关联起来,表示买家正在购买商品。订单对象可以和买家和商品对象关联起来,表示订单是买家购买商品的结果。 此外,我们还可以使用序列图来表示系统中的交互过程。如购买商品的过程可以用序列图来表示买家选择商品、生成订单、支付订单和确认收货等过程。 最后,我们可以使用状态图来表示系统中的状态变化。如订单的状态可以包括待支付、已支付、待发货和已完成等状态。 通过这些UML图,可以清晰地描述电商系统的结构和功能,帮助系统设计人员理解和沟通系统设计。同时,UML还可以用于系统的分析、测试和维护等工作。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值