以Android源码分析初识UML（一）

前几天在看设计模式，每次看到UML的时候就是一头雾水，不懂那些条条杠杠是什么东东，没办法，既然踏上软件开发这条不归路，我已经没有后退和后悔的余地了，除了搬运代码，不知道还有什么生存能力，对于踏上不归路的坎坷，后面想详细写篇帖子来讲述，都是眼泪。。。

对于接触Android不久的小伙伴，看到这张图可能会有点懵逼了，其实没什么的，打开源码后，这些都是基础，几个继承关系而已，或者搞过activity和context关系的小伙伴也应该很清楚这个结构。

好了，言归正传，我们逐步分析，先说Context类：
打开源码便会看到Context是个抽象类，类图分三层，第一层指的是类名称，命名都是按照Java的规范，如果是抽象类，则用斜体表示，第二层用来表示特性（字段和属性），可分为两部分，前部分用来表示访问域和名称，后部分表示返回值类型或值（可缺省），以”:”分隔开，第三层表示操作（方法和行为），同第二上一样分为两部分。

“+”表示public，”-“表示private，”#”表示protected，对于抽象方法采用斜体表示。

再来分析下ComponentCallbacks2：
这是一个接口图，与类图的主要区别是顶部会有<< interface>>，接口图可分为两层，第一层表示接口名称，第二层表示接口方法。

接下来分析下类与类、类与接口之间的关系，首先分析上述的继承和实现接口关系，类与类之间的继承通过空心三角形加上实线来表示，子类指向父类。而接口的表示是空心三角形加上虚线来表示，实现类指向接口。

再来看下MainActivity和presenter之间的关系属于一种关联关系，关联关系是类与类之间的联接，指的是一个类知道另一个类的属性和方法。关联可以是双向的也可以是单向的，双向的表示一般是没有箭头或者双箭头，从耦合度的角度来说，双向关联的耦合度很高，这就是我们平时使用MVP开发的过程中，在业务逻辑复杂的情况下，view和presenter之间交互很频繁。单向关联是一个箭头加上一条直线完成，单向关联在开发过程中更为普遍。

现在再看下Activity和Activitys之间的关系，这种关系属于聚合关系，在《大话设计模式》中是这样描述的，聚合表示一种弱的”拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分，这也是《大话设计模式》作者摘抄《设计模式》（第二版）的原话，看到这句话的时候，好像在高中数学上看到过这样的逻辑题，理解的迷迷糊糊，当我看到《Java与模式》中这层关系讲解的时候，瞬间有一种山重水复疑无路，柳暗花明又一村的感觉，聚合是一种整体和个体的关系，比如汽车和轮胎，汽车和发动机，这样解释，是不是瞬间明白了好多。

我们都知道fragment是基于activity的，3.0才开始出现的。有的书上说一个fragment就是activity的一个任务，可以把一个activity分成多个fragment，相信不少小伙伴和我一样，在开发过程中经常遇到activity丢失现象，activity被后台释放，当重新返回界面的时候，fragment找不到activity而出现闪退，这就是一种依赖关系，依赖关系总是单向的，在日常开发中，除了fragment和activity的关系外还有好多依赖关系的例子，比如A、B是两个不同的类，在A里面有B类型的全局或者局部变量，这就是一种依赖关系，A销毁，此类中B就不能单独运行。依赖关系，我们采用虚线加上箭头表示。

最后再看一种关系，合成关系是一种强的”拥有”关系，部分对整体来说不可缺少的关系，部分和整体的生命周期一样，比如飞鸟和翅膀的关系。在我们日常开发过程中也挺多的，比如一个类中包含一个内部类或者一个接口类，这都是一种合成关系。

最初接触UML的时候还是在校期间准备考软考的时候，一晃四年过去了，这四年的开发过程中也很少使用UML，只是偶尔在设计模式中或者一些大神的帖子中看到过，对于最近的学习，也算是一次全新的学习，说是初识也不为过吧。以上的分析可能存在一些问题，欢迎批评指正。

参考文献：《大话设计模式》、《Java与模式》