用uml总结项目的代码架构

之前的经验

之前习惯把正在做的项目， 通过uml的方式进行下总结， 主要目的是了解清楚代码架构， 方便记忆， 方便查找关键代码。
但之前总结的并不规范， 类和类之间的关系， 只要存在联系， 就用关联 -> 线把两个类联系起来。
这次换工作， 需要交接工作， 把天气项目的代码架构总结清楚。并且下次工作， 去做架构师， 有必要把uml的技能培养的更专业些， 体现出和工作3，5年的普通工程师的差距出来。

类和类之间的关系。

一共有6种关系.
继承和实现就不必再说了。
容易混淆的是 关联， 聚合， 合成， 依赖， 这四种关系。
这篇文章主要也是为了把这4种关系的差异给弄明白, 以后再画uml图的时候也能画的更加专业一下.

关联关系

本质上来说, 就是从A能找到B. 也就是说, 通过A的对象, 可以访问的到B的对象.
在java中的体现就是普通的成员变量.
uml中的表现: A->B 实心带箭头的线. 表示从A类能找到B类.

public class A {
    private B b;
}

这种基础类型的成员变量, 就叫做Field, 一般在uml中不用画出来 Me 和 String这种java基础类型类之间的关系.

public class Me {
    // Field
    String name;

    //朋友
    Friend f;
}

聚合关系

在java中的体现, 就是那种集合类型的成员变量.
可以把聚合关系理解为更细化的关联关系, 或者叫做关联关系的一种特殊类型.

uml中的表现: 空心菱形线, 并且空心菱形指向整体.

public class ClassRoom {
    List<Student> students;
}

聚合关系是: 整体和部分的关系.
ClassRoom "空心菱形" - Student

合成关系

合成关系和聚合关系是相似的, 也是整体和部分的关系.
区别点是, 两者的关系更加的紧密, 核心区别是, 整体的生命周期决定了部分的生命周期.
在java中的体现, 同样是那种集合类型的成员变量.
uml中的表现: 实心菱形线, 并且实心菱形指向整体.

public class 人 {
    List<四肢> s;
}

在实际工作中, 有时候不太好区分是聚合关系还是合成关系, 不必太纠结于这一点细微的差别. 统一都用聚合关系的空心菱形来表达也未尝不可.

依赖关系

uml中的表现: 带箭头的虚线.

在java中的体现: 方法中的局部变量, 方法参数和方法的返回值. 这3个地方出现的类, 就是依赖关系.

从本质上来说, 如果A和B是关联关系的话, 就是从A能找到B. 如果是依赖关系的话, 是无法实现从A的对象访问到B的对象.

public class Test {
    public void m1() {
        User u = new User(); //依赖关系
    }
}

作为对比:

public class Test {
    User u = new User(); //如果不是局部变量, 变成了成员变量的话, 
//这时候, 就变成了关联关系. 从代码思想的角度看, 也就是说客户拿到了Test类的对象, 也就可以访问到User类的对象.

    public void m1() {
        //User u = new User(); //依赖关系
    }
}

总结

把这6种关系总结完后, 以后我画的uml图就能达到专业水准了, 离真正意义上的架构师也更近了一步.

refer to:

杜聚宾 动力节点的视频讲座.
这个老师讲的挺明白的, 有时间的时候可以再学习下他的其他课程.

---DONE.------