UML（第一部分）与设计模式原则

一、UML

1.统一建模语言： 是一种直观化 明确化 构建和文档化软件系统产物的通用可视 化建模语言。

UML是一种可视化的建模语言，它能让系统构造者使用标准的、易于理解的方式建立起能够表达交流他们想象力的系统蓝图，并且提供一种机制，以便不同的人之间有效地共享和交流设计结果。我理解为一个软件项目从开发到正式上线以及后期维护过程中，方便开发者、设计者、需求方之间沟通。

UML提供了一些可以相互组合为图表的图形元素，以便我们用多个视图来展示一个系统。这组视图成为一个模型，大多数UML模型只包含后续图中的子集。一个UML模型并没有描述系统如何实施。只描述了一个系统中有什么、要做什么。

2.概念和模型可以被划分为以下的范围：

静态结构、动态行为、实现构造、模型组织、扩展机制

3.系统（系统）：系统是一组互相依赖和互相交互的一组组件组成的整体，一个系统可以用静态的结构和动态的行为两方面来描述

分析（分析）：分析是一个将复杂事物分解成小的组成部分的过程

设计（设计）：设计是使用建模元素描述一个事物规格的过程，改规格满足一定的需求，并符合一定的限制条件。

像我们课本上的类图也是一种静态试图。

二、设计模式

对于设计模式，《C#面向对象设计模式纵横谈》视频中也提到了面向对象设计模式与原则。指出OOPL并非面向对象的全部：

并不是使用了OOPL就是使用了面向对象设计与开发；

对OOPL的面向对象学习好了并不等于面向对象设计与开发通透了；

单纯从编程语言上获得的面向对象知识，不能够胜任面向对象设计与开发。

也指出要想设计 “好的面向对象 ”必须要：① 遵循一定的面向对象设计原则 ②熟悉一些典型的面向对象设计模式

同时也要注意：

1.针对接口编程，而不是针对实现编程：客户只需要知道对象中有你所想要的接口即可。

2.优先使用对象组合，而不是类继承。

3.封装变化点：实现对代码的分隔，在对一部分代码修改时，不影响其他部分代码。

4.使用重构得到模型：设计模式与项目之间并不是一一对应的关系，想要找到合适的设计模式就需要不断的对设计模式进行重构以切合项目的具体需求。

遵循一定的面向对象设计原则：

1 单一职责原则：

如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。

这个原则的优点是：可以降低类的复杂性、提高可读性和可维护性，降低变更引起的风险。也建议我们面向接口单一原则。具体实现的话。具体问题具体分析。

2 里氏替换原则：

子类必须完全实现父类的方法，子类可以有自己的个性，覆盖或实现父类的方法时输入参数可以被放大，覆盖或实现父类的方法时输出结果可以被缩小范围。

这个原则比较好理解。

子类必须完全实现父类的方法。

子类可以有自己独立的属性和方法。

 覆盖或实现父类的方法时输入参数可能会被放大。（如果子类给的参数范围大于父类，不会被执行到，要求子类给参数类型必须等于父类）。

 覆盖或者实现父类的方法时输出可以被缩小范围。（父类的返回参数类型必须大于子类）

3 依赖倒转原则：依赖倒置的两个规定就是：1、高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。2、抽象不应该依赖于具体，具体应该依赖于抽象。

对象的依赖方式通过三种方法：构造函数传递依赖对象、setter方法传递依赖对象、接口声明依赖对象来实现。

①.每个类尽量都有接口或抽象类，或者接口和抽象类两者都具备。

②.变量的表面类型尽量是接口或抽象类。

③.任何类都不应该从具体类派生。

④.尽量不要重写基类的方法。如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要重写。

⑤.结合里氏替换原则使用。

4 接口隔离原则：接口隔离原则是基于单一职责原则来的，有了细粒度的职责分化，才会有接口隔离的产生。

①.一个接口只服务于一个子模块或业务逻辑。

②.通过业务逻辑压缩接口中的public方法，接口市场去回顾，尽量让接口达到“浑身都是筋骨肉”，而不是“肥嘟嘟”的一大堆方法。

③.已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。

④.了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的就照抄。还是深入了解业务逻辑再具体问题具体分析。

5  迪米特法则： 一个对象应当对其他对象有尽可能少的了解。也就是说：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

①.只与直接的朋友类交流。

②.朋友类之间要有距离。要尽量去降低类之间的耦合。

③.是自己的就是自己的。如果一个方法放在本类中也可，也不增加类间关系，也不产生负面影响，那就放置在本类中。

④.慎用Serializable。

6 开闭原则：开闭原则主要体现为：对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况；对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。

①.使用抽象约束。

②.使用元数据（配置参数）控制模块行为

③.制定项目章程

④.了解封装变化