SOLID设计原则

SRP：单一指责，每个类，每个方法专注一件事，小方法构成大功能。但是拆分到何种程度？取决于业务，当某个业务变更时发现会同时修改几个方法，那么可以考虑合并。
OCP：对修改关闭，对扩展开放，尽量不修改原有功能，原有功能已经上线，修改有风险，所以设计时考虑可扩展性，能通过扩展实现新的需求。实现OCP的思路有：多态，不要硬编码
LSP：里氏替换，对于有继承关系的类，使用子类替换父类。
ISP：接口隔离，一个大接口不如多个小接口，粒度小，灵活性好，使用小功能组装成大功能，使用一个小功能没有必要引入过多的其他功能。那么接口小到何种程度？也值得思考。
DIP：依赖抽象，接口，而不是依赖具体实现。Spring中体现的很明显。

uml图

类的关系有泛化(Generalization)、实现（Realization）、依赖(Dependency)和关联(Association)。
其中关联又分为一般关联关系和聚合关系(Aggregation)，组合关系(Composition)。

类的关系
====泛华(继承)
====实现(接口)
====依赖(方法参数、返回值)
====关联
========关联关系(成员变量)
========聚合关系(弱依赖)
========组合关系(强依赖)

车的类图结构为<>，表示车是一个抽象类；
它有两个继承类：小汽车和自行车；它们之间的关系为实现关系，使用带空心箭头的虚线表示；
小汽车为与SUV之间也是继承关系，它们之间的关系为泛化关系，使用带空心箭头的实线表示；
小汽车与发动机之间是组合关系，使用带实心箭头的实线表示；
学生与班级之间是聚合关系，使用带空心箭头的实线表示；
学生与身份证之间为关联关系，使用一根实线表示；
学生上学需要用到自行车，与自行车是一种依赖关系，使用带箭头的虚线表示；

泛化(generalization)

表示is-a的关系，是对象之间耦合度最大的一种关系，子类继承父类的所有细节。直接使用语言中的继承表达。在类图中使用带三角箭头的实线表示，箭头从子类指向父类。

实现（Realization）

在类图中就是接口和实现的关系。这个没什么好讲的。在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口。

依赖(Dependency)

对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类。
在最终代码中，依赖关系体现为类构造方法及类方法的传入参数，箭头的指向为调用关系；依赖关系除了临时知道对方外，还是“使用”对方的方法和属性；

关联

关联关系(association)

关联关系是用一条直线表示的；它描述不同类的对象之间的结构关系；它是一种静态关系，通常与运行状态无关，一般由常识等因素决定的；
它一般用来定义对象之间静态的、天然的结构；所以，关联关系是一种“强关联”的关系；
比如，乘车人和车票之间就是一种关联关系；学生和学校就是一种关联关系；
关联关系默认不强调方向，表示对象间相互知道；
在最终代码中，关联对象通常是以成员变量的形式实现的

聚合关系(Aggregation)

表示has-a的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。如公司和员工的关系，公司包含员工，但如果公司倒闭，员工依然可以换公司。在类图使用空心的菱形表示，菱形从局部指向整体。

组合关系(Composition)

表示contains-a的关系，是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向整体。
http://www.uml.org.cn/oobject/201104212.asp
http://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html

设计模式原则和UML图

2017-04-30
note