六大设计原则

开闭原则 --对扩展开放对修改关闭 --软件在生命周期内会发生变化，开闭原则告诉我们应该通过拓展软件实体行为来实现变化而不是修改已有代码来完成变化 --改变要尽量少

 

变化类型 ： 逻辑变化 子模块变化 可见视图变化

 

优点：1.已有代码是通过了测试的，减少了测试成本

2.提高复用性  --颗粒度越小，被复用的可能性就越大，在修改代码的时候当有原子逻辑改动时，不复用的代码需要找到分散在项目中的所有相同逻辑，不利于维护。

3.提高可维护性 

4.面向对象开发的要求 --抽象是对不变事物的总结，实体实现的是可以变化的。设计之初规定不变事物，留下接口等待可能转变为现实

 

使用：

  抽象约束--接口或抽象类约束包含三层含义

1. 通过接口或者抽象类约束扩展不存在public方法 

2. 参数类型、引用对象尽量用接口或者抽象类，而不是实现类

3. 抽象层保持稳定，一旦确定不允许修改

    元数据控制块行为

        1.尽量用配置参数来影响程序行为

    制定项目章程

        1.章程很重要，约定优于配置  --减少配置的手段 例子：springboot 注释

    封装变化

        1.将相同的变化封装到一个接口或者抽象类中

        2.将不同的变化封装到不同的接口或者抽象类中

开闭原则是个终极目标 任何人都不能百分之百做到 对于开闭原则的实现由其余5大原则来体现。个人看法：原则终归是原则，在现实层面常常会违背，考虑到工作量，技术架构等等，比如为了减少工作量引入DAO自动生成工具，带来了方便，但是同时系统不符合了开闭原则，但是考虑到工作量以及公司体量并不是不可以接受，水至清则无鱼，具体问题具体分析。

单一职责原则

定义：有且仅有一个原因引起类的变更

好处：类的复杂性降低，职责有明确定义

            可读性提高，复杂性降低，容易维护

            变更风险降低，易于扩展

单一职责原则 --尽量做到接口单一，类设计尽量做到只有一个原因引起变化

里氏置换原则

定义：所有引用基类的地方必须透明地使用其子类对象

4层含义：

1.子类必须完全实现父类方法

2.子类可以有自己的“个性”

3.覆盖或实现父类方法时输入参数可以被放大

4.覆盖父类方法时输出结构可以被缩小

在项目中把子类当父类使用，子类个性体现不出来。如果把子类单独作为一个业务来使用，会让代码耦合关系变得扑朔迷离。

依赖倒置

定义：高模块不应该依赖低模块，应该依赖于其抽象 抽象不应该依赖细节 细节应该依赖抽象

优点：减少类的耦合，提高系统稳定性，降低并行开发引起的风险，提高可读性可维护性

简而言之就是面向接口编程。

接口隔离原则

定义：类间依赖关系应该建立在最小的接口上 --接口应该尽量细化--接口中的方法应该尽量少

4层含义：

1.接口尽量小

2.接口要高内聚

3.定制服务

4.接口设计是有限度的

接口颗粒度大小根据需求变更有关，颗粒度大了，灵活性降低，需求变更需要修改代码，颗粒度小了，接口数量剧增，维护与开发难度增大。

迪米特法则

定义：一个对象应该对其他对象有最少的了解

含义：

1.只和耦合类对象交流

2.尽量降低耦合关系

3.如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中

4.谨慎使用Serializable

核心是解耦，只有弱耦合才能提高类的复用率。但一味解耦会产生大量中间类和跳转类，可能导致系统复杂性提高，为维护带来困难。