标签：提高 16px 具体类 就是 设计师 里氏替换原则 接口 逻辑 isp
UML第一部分总结
UML概述
UML(Unified Model Language )统一建模语言，又称标准建模语言。是用来对软件密集系统进行可视化建模的一种语言而非编程语言。作为一个支持模型化和软件系统开发的图形化语言，UML为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。
UML视图
视图在最高层次可以划分为三个领域: 结构性分类 动态行为和模型管理
结构性分类:描述了系统中的事物和事物间的关系，分类包括类 用例构件和结点，分类提供了动态行为构建的基础，分类视图包括静态视图。用例视图和实现视图
动态行为:描述了系统时间上的行为 行为可以用静态视图中系统快照的一系列变更来描 述 行为视图包括状态机图 活动图和交互图,模型管理描述了用层次式的单元对模型自身的组织.包是模型的通用组织单元,特殊 的包包括模型和子系统.
模型管理:视图与其它视图相交迭,为团队工作和配置控制把它们组织起来。
UML视图之用例图
用例图展现了一组用例、参与者(actor)以及它们之间的关系。用例图从用户角度描述系统的静态使用情况，用于建立需求模型。
UML视图之静态图
静态图包括类图，包图和对象图。
类图(Class Diagram)：展现了一组对象、接口、协作和它们之间的关系。类图描述的是一种静态关系，在系统的整个生命周期都是有效的，是面向对象系统的建模中最常见的图。
包图(Package Diagram)：包图描述系统的分层结构。在UML1.1版本中，包图不再看作一种独立的模型图。
对象图(Object Diagram)：展现了一组对象以及它们之间的关系。对象图是类图的实例，几乎使用与类图完全相同的标示。
设计模式的六大原则
一，单一职责原则(SRP)
单一职责原则概念：
引起类变化的原因不能多于一个。也就是说每一个类只负责自己的事情，此所谓单一职责。
单一职责的原因：
因为每一个职责都是变化的，所以当需求变化时，该变化会反映为类的职责的变化，当一个类承担了多余一个的职责，那么引起它变化的原因就会有多个，最终职责的耦合将会导致设计的脆弱，说白了就是一个
类承担了几个职责，其中一个出现了问题就会影响整个类。
单一职责原则优劣：
更变是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性和可读性都有非常大的帮助。单一职责听起来很简单，做起来却很
难，因为我们总是自然而然地倾向与把职责结合在一起（习惯于面向过程的思维）。
二，里氏替换原则(LSP)
里氏替换原则概念：
只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
里氏替换原则包含的4个含义：
1.子类必须完全实现父类的方法
2.子类可以有自己的个性
3.覆盖或实现父类方法时输入参数可以被放大
4.覆写或实现父类的方法时输出结果可以被缩小
里氏替换原则优劣：
采用里氏替换原则可以增强程序的健壮性，版本升级时也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同
的子类完成不同的业务逻辑。采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀把子类单独作为一个业务来
使用，则会缺乏类替换的标准。
三，依赖倒置原则（DIP）
依赖倒置原则包含三层含义:
1.高层模块不应该依赖低层模块，两者都应该依赖其抽象
2.抽象不应该依赖细节
3.细节应该依赖抽象
依赖倒置原则优劣：
减少类间的耦合性，提高系统间的稳定性，降低并行开发引起的风险，提高代码的可读性和维护性。依赖倒置原则没有实现，就别想实现对扩展开放，对修改关闭。
依赖倒置原则使用时一定要遵守以下几点：
1.每个类尽量都有接口或抽象类，或者抽象类和接口两者都具备
2.变量的表面类型尽量是接口或者是抽象类
3.任何类都不应该从具体类派生
4.尽量不要覆写基类的方法
5.结合里氏替换原则使用
四，接口隔离原则（ISP）
接口隔离原则概念：
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
接口隔离原则优劣
优点：
1.将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性
2.接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性
3.使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义
4.能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码
缺点：
如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
五，迪米特法则（LoD）
迪米特法则概念：
一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少。
迪米特法则的优劣
优点：
迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。
缺点：
1.遵循类之间的迪米特法则会使一个系统的局部设计简化，因为每个局部都不会与远距离的对象有直接的关联；但也会造成不同模块之间的通信效率降低，会使系统的不同模块之间不容易协调。
2.在系统中造出大量的小方法，散落在系统的各个角落。这些方法仅传递间接的调用，与系统的商务逻辑无关。
3.当设计师试图从一张类图中看出总体的架构时，这些小方法会造成迷惑和困扰。
应用迪米特法则的注意事项：
1.在类的划分上，应该创建有弱耦合的类。
2.在类的结构设计上，每一个类都应当尽量降低成员的访问权限。
3. 在类的设计上，只要有可能，一个类应当设计成不变类。
4. 在对其他类的引用上，一个对象对其它对象的引用应当降到最低。
5. 尽量降低类的访问权限。
六，开闭原则（OCP）
开闭原则概念：
一个软件如类，模块和函数应该对扩展开放，对修改关闭。
使用开闭原则的好处：
? 提高复用性
? 提高可维护性
使用开闭原则应该注意：
1.抽象约束
2.元数据控制模块行为
3.指定制定项目章程
4.封装变化
标签：提高 16px 具体类 就是 设计师 里氏替换原则 接口 逻辑 isp
原文地址：https://www.cnblogs.com/yiyeguhong/p/14344739.html
