设计模式-面对对象设计基本原则理解

前言：

日常开发项目，如果只是单纯的一期开发、后面什么也不负责的话，那你开发自己通过就行（没人要求的话）；

但是如果要持续性开发一期、后期进行维护性开发，或者一个大的团队中进行开发时，基本都要了解一些开发对象的原则，为了扩展开发加理解，低耦合、可扩展、可复用性开发，了解一些原则会更有效的代码。

这些原则都是经过实践得出的，了解之后会得到常规开发思路以及设计代码逻辑。

 一：单一职责原则

一个类只负责一个功能模块中的相应代码开发。

例如一个常规接口开发：控制层cotroller 加 service接口层开发、以及db数据库交互等模块，每个类都有自己职责模块，

不要进行合并代码开发，不利于后期维护、以及代码浏览、审查功能。

其次：一个类承担的功能过多，就相当于将这些功能耦合在一起，当其中一个功能变化时，可能会影响模块开发，因此要将这些功能进行分离，

例如：如果service接口层和db数据库交互放在一期，如果要变更数据库交互技术框架，是不是要考虑很多代码、更改、检查繁琐。

二：开闭原则

软件实体应对扩展开放，而对修改关闭，

即软件实体应尽量在不修改原有代码的情况下进行扩展。

这个就是怎么样考虑，更方便的后期维护开发了，新需求变动时，尽量不要更改原有代码，

1.以多态方式进行维护开发

2.新增接口方式进行开发

3.整体框架优化，例如之前有一个项目，所有的接口逻辑主体都在一个类中，

在这个类中，主要有三个抽象接口，业务规则校验、参数检查、数据库交互，

每一个接口或者每个交易，都自定义一个实现层，继承基类，实现三个api,后期开发新接口，完全只是新增一个接口类，实现三个api即可

三：里氏代换原则

所有引用基类对象的地方能够透明地使用其子类的对象；
在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象；

里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

简单点理解就是：

在使用继承时，父类A,子类B,

所有的代码在引用父类A地点，也能够替换成B进行使用，就是为了子类尽量不要去重写父类的方法，否则，不同的人有不同的看法，重写多了，就不利于后期维护、扩展、替换了。

四：依赖倒转原则

抽象不应该依赖于细节，细节应该依赖于抽象；

简单的，业务实现层方法，使用接口进行开发。
依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情

在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。

五：接口隔离原则

使用多个专门的接口，而不使用单一的总接口；
即客户端不应该依赖那些它不需要的接口，每一个接口应该承担一种相对独立的角色，不干不该干的事；

这个和单一职责优点类似，设计接口类时，不要混杂，用功能模块进行划分、等进行有区别度的划分。

如果接口承担了太多职责，一方面导致该接口的实现类很庞大，在不同的实现类中都不得不实现接口中定义的所有方法，灵活性较差，如果出现大量的空方法，将导致系统中产生大量的无用代码，影响代码质量；另一方面由于客户端针对大接口编程，将在一定程序上破坏程序的封装性，客户端看到了不应该看到的方法，没有为客户端定制接口。
 

六：合成复用原则

尽量使用对象组合，而不是继承来达到复用的目的
复用时要尽量使用组合/聚合关系（关联关系），少用继承。

通过继承来进行复用的主要问题在于继承复用会破坏系统的封装性，因为继承会将基类的实现细节暴露给子类，由于基类的内部细节通常对子类来说是可见的，所以这种复用又称“白箱”复用，如果基类发生改变，那么子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；而且继承只能在有限的环境中使用（如类没有声明为不能被继承）；

例如：

public class Base{

        ...等等api

}

public class BaseA{

        //通过引用base对象，来使用上层方法

        private Base base;

        ...等等baseA特有的api;

}
 

七：迪米特法则

一个软件实体应当尽可能少地与其他实体发生相互作用
当其中某一个模块发生修改时，就会尽量少地影响其他模块，扩展会相对容易，这是对软件实体之间通信的限制，迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。

提取公共类，各业务模块与公共类模块进行交互，此公共类模块不能涉及太多业务层次代码，只为完成单一功能,

重点时，业务模块直接尽量不要直接访问，互相调用api,要方便后续扩展