标签:temp 构造函数 interface 过多 工作 传递依赖 包含 upload strategy
一个类只负责一项职责。 当超过一项职责需要负责时,需要增加新的类来负责新的职责,而不是在类中个性代码。
如果一个类承担的职责太多,就是高度地职责耦合,非常不利于扩展功能。这是非常脆弱的设计。 容易发生修改一个地方而影响其他地方的情况。
遵循单一职责原则的优点:
里氏代换原则(Liskov Substitution Principle, LSP):所有引用基类(父类)的地方必须能透明地使用其子类的对象。
里氏代换原则告诉我们,在一个软件系统中,子类应该可以替换任何基类能够出现的地方,并且经过替换以后,代码还能正常工作。子类也能够在基类的基础上增加新的行为。
例如有两个类,一个类为BaseClass,另一个是SubClass类,并且SubClass类是BaseClass类的子类,那么一个方法如果可以接受一个BaseClass类型的基类对象base的话,如:method1(base),那么它必然可以接受一个BaseClass类型的子类对象sub,method1(sub)能够正常运行。反过来的代换不成立,如一个方法method2接受BaseClass类型的子类对象sub为参数:method2(sub),那么一般而言不可以有method2(base),除非是重载方法。
里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。
包含4层含义:
不遵循里氏代换原则的后果是,写代码出错的机率会大大增加。
定义:1.高层模块不应该依赖低层模块,二者都应该依赖其抽象; 2.抽象不应该依赖细节;细节应该依赖抽象。
问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成。这种场景下,类A一般是高层模块,负责复杂的业务逻辑;类B和类C是低层模块,负责基本的原子操作;假如修改类A,会给程序带来不必要的风险。
解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实:相对于细节的多变性,抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中,抽象指的是接口或者抽象类,细节就是具体的实现类,使用接口或者抽象类的目的是制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。
传递依赖的三种写法:
1.构造函数传递依赖对象
2.Setter方法传递依赖对象
3.接口声明传递依赖对象
深入了解可以看:轻松学,浅析依赖倒置(DIP)、控制反转(IOC)和依赖注入(DI)
举例来说明接口隔离原则:
(图1 未遵循接口隔离原则的设计)
这个图的意思是:类A依赖接口I中的方法1、方法2、方法3,类B是对类A依赖的实现。类C依赖接口I中的方法1、方法4、方法5,类D是对类C依赖的实现。对于类B和类D来说,虽然他们都存在着用不到的方法(也就是图中红色字体标记的方法),但由于实现了接口I,所以也必须要实现这些用不到的方法。
可以看到,如果接口过于臃肿,只要接口中出现的方法,不管对依赖于它的类有没有用处,实现类中都必须去实现这些方法,这显然不是好的设计。如果将这个设计修改为符合接口隔离原则,就必须对接口I进行拆分。在这里我们将原有的接口I拆分为三个接口,拆分后的设计如图2所示:
(图2 遵循接口隔离原则的设计)
迪米特法则有很多种说法,比如:一个类应该应该对其他类尽可能了解得最少;类只与直接的朋友通信等等。但是其最终目的只有一个,就是让类间解耦。
就是说一个对象应该对其他对象保持最少的了解。正如最少知识原则这个定义一样,一个类应该对其耦合的其他类或所调用的类知道得最少。所耦合的类内部无论如何复杂,怎么实现的我都不需要知道,我只调用你public出来的这些方法,其他都不用知道。
所谓开放封闭原则就是软件实体应该对扩展开放,而对修改封闭。开放封闭原则是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化,降低耦合,而开放封闭原则正是对这一目标的最直接体现。
开放封闭原则主要体现在两个方面:
为什么要用到开放封闭原则呢?
软件需求总是变化的,世界上没有一个软件的是不变的,因此对软件设计人员来说,必须在不需要对原有系统进行修改的情况下,实现灵活的系统扩展。
如何做到对扩展开放,对修改封闭呢?
实现开放封闭的核心思想就是对抽象编程,而不对具体编程,因为抽象相对稳定。让类依赖于固定的抽象,所以对(抽象类)修改就是封闭的;而通过面向对象的继承和多态机制,可以实现对抽象体的继承,通过覆写其方法来改变固有行为,实现新的扩展方法,所以对于扩展就是开放的。
对于违反这一原则的类,必须通过重构来进行改善。常用于实现的设计模式主要有Template Method模式和Strategy 模式。而封装变化,是实现这一原则的重要手段,将经常变化的状态封装为一个类。
代码参考例子:以银行业务员为例
标签:temp 构造函数 interface 过多 工作 传递依赖 包含 upload strategy
原文地址:https://www.cnblogs.com/TvvT-kevin/p/9320910.html