软件设计的五大原则

一.UML的组合和聚合

1.组合:生命周期相同.如蜜蜂和其尾针的关系

2.聚合 ：整体与局部的关系，两者都有其各自的生命周期。如鸟和鸟群的关系。

二.软件架构设计的目的都是为了达到强内聚低耦合

三.五大原则

1.开闭原则-OCP：对修改关闭，对拓展开放。

开闭原则提倡应该针对接口编程，而不是针对实现编程。因为针对实现编程，如果以后再添加一个新的功能模块就可能导致整体的功能都要修改。如下图：

把所有方法都放在同一个类中势必导致这个的耦合度降低，想要增加一个方法都可能面临着重写整个类的风险。

正确的做法应该是面对接口编程：

创建一个接口，具体怎么实现就要需求了，然后再调用就行了，这样就拓展就开放了。

2.单一职责原则：不要存在多于一个导致类变更的原因 。

假设一个类由两个具体的方法构成，一个方法的变更导致了整个类的功能出现故障。

强内聚低耦合：把一个这个类的功能拆分成两个类，负责职责1的类1和职责2的类2
一个类/接口/方法只负责一项职责
优点：降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险
类的单一职责，接口的单一职责，方法的单一职责。把一个类/接口/方法拆分成清晰的模块，再聚合起来。但是项目构建过程中面向接口编程要考虑接口和方法的单一指责，类的单一指责视具体情况而定，因为如果再面向接口编程过程中同时接口和类遵守单一指责会导致类的数量爆炸
 

3.依赖倒置原则：高层模块不应该依赖底层模块，二者都应该依赖其抽象。

1.抽象不应该依赖细节；细节应该依赖抽象
2.针对接口编程，不要针对实现编程
优点：可以减少类间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，降低修改程序所造成的风险

如图：

最后达到的效果是：

4.接口隔离原则：用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口

1.一个类对一个类的依赖应该建立在最小的接口上
2.建立单一接口，不要建立庞大臃肿的接口
3.尽量细化接口，接口中的方法尽量少

重点：注意适度原则，一定要适度。接口设计过大过小都不好
优点：符合我们提倡的高内聚低耦合的设计思想，从而使得类具有很好的可读性，可拓展性和可维护性

接口隔离原则和单一职责原则的区别：
单一职责原则指的的类，方法，接口的职责是单一的，强调的是职责是单一的，例如游泳这个方法，可以有多种游泳的方式
接口隔离是指在接口层面上的，减小接口间的依赖，主要约束的是针对抽象整体，框架的

错误例子如下图：

Dog这个接口实现类，Dog是没有fly这个行为的，如果接口的方法过多，必然导致接口臃肿，这是应该细分模块，把Dog的行为抽取到另外一个接口。如下图：

这样，你想添加一个新的功能，实现哪个需要的功能接口即可，而不是把一堆接口堆在一起，这样软件的架构的可重用性就很差了。

5.迪米特原则：一个对应应该对其他对象保持最少的了解，又叫最少知道原则。强调只和朋友交流，不和陌生人说话

尽量降低类与类之间的耦合
优点：降低类之间的耦合
注意：要适度运用迪米特原则，因为如果过度使用迪米特原则会导致很多中间类
朋友：出现在成员变量，方法输入，输出参数的类成为朋友变量
而出现在方法体内部的类不属于朋友类
boss给teamleader下指令查询课程数量，teamleader查询course数量后直接返回一个结果给boss就行了，而Boss不需要知道具体查询course的细节。

如下图：

Boss类通过Teamleader要course，teamleader只需要返回一个结果给Boss即可，Boss不需要知道teamleader是如果获取course的以及course是如何产生的。