1.开闭原则
实现开闭原则的核心是抽象,将变化部分和不变化部分区分开来,这有利于功能的扩展
一句话概括就是,对扩展是开发的对修改是关闭的.
在实际的编码当中虽然不能做到百分之百按照开闭原则来,但是朝着这个目标去编码。
个人认为开闭原则从软件的系统的角度来说:软件系统的个个功能组件,如菜单、模块、类、以及功能等等,应该在不修改原有代码的基础上增加新的功能.同时对于经常发生变化有关的值,
可以进行封装.至于开闭原则中的开始对组件的功能扩展是开发的,是允许对其功能扩展的。开闭原则的闭,可以认为是原有代码的修改是关闭的。既不动原有代码,又能增加新的组件功能。
简而言之我们可以把开闭原则理解成——————根据需求随意添加新的类,但是不需要修改原有的代码
2。单一职能原则
1.防止相同类型的职责分离到不同的类中,即我们需要提高代码的可重用性
2.同一个类无需编制多余的职责,即用情专一继承了中国男人的传统美德
打个简单的比喻,酒店的厨师,他只负责做菜,而不负责送菜,洗碗的阿姨只负责洗好碗,等等。。
优点:
1.有助于清楚的希求设计与编码的思路
2.有助于简化维护,编码,测试的流程
3.将复杂的问题简单化,有助于代码的重用
4.职责时间消除耦合,有利于系统的扩展。
实现单一职能原则——————类的大小要适中,不能太小会疲于维护.如 添加 修改 删除,如果按照单一原则可以将其分为3个类,其实这个时候可以将这些都放到操作类当中
3.里氏替换原则
我们在涉及类的继承设计的时候可以从"父类不能替换子类,而子类型可以替换基类",的思路引导下,进行里式代换的原则的实现。
首先正确地进行继承设计,所有基类的方法都要在其子类中得到实现或者重写,并且子类不能写出与业务无关的多余方法
其次最优的继承层次设计,当其他应用类调用业务功能类时,应该调用其业务功能的基类而不应该直接去调用业务功能的子类;
里氏替换原则在策略模式,合成模式,代理模式,都有充分的体现
4.依赖倒换原则
其定义有两点;
1.高层不应该依赖于底层,两者都应该依赖于抽象,抽象不应该依赖于细节,细节应当依赖于抽象.简而言之,就是我们在设计系统运用依赖倒换原则的时候,
需要运用抽象来进行分析不要一开始就关注细节。
2.针对接口编程,不要针对实现编程,我们可以运用依赖倒换原则,可以通过接口来进行类,变量,参数,方法等的声明,并且禁止用实现类去做以上的声明。
如何去实现依赖倒换原则
1.从实现类与抽象的角度进行分析,我们在运用具体实现去集成抽象类时,需要保证引用基类之处可愿意修改成其子类
2.从层次的关系进行分析,需要定义清晰的层次关系,使每个层次通过接口的方式进行.
3.从对象的构造角度进行分析,如果创建的是动态对象,使用依赖倒换原则。如果创建的是一些静态的具体类并且变化率很低,则我们无需再创建其类去集成,以规避维护多余代码的风险。
5.接口隔离原则
其定义有三点
1.不应该强迫客户(其子类)依赖于它们不用的方法
2.一个雷对另一个类的依赖性应当是建立在最小的接口上
3.要将接口理解成角色
接口的隔离原则可以从以下几个角度去思考
1.首先从业务逻辑的角度去考虑接口,我们可以把某类功能也没设计成接口,如影片中的正角,反角可以设计成接口,然后正角的演员可以当成是实现类。
2.其次根据场合和调用者的情况消除无关的方法,只提供同类型角色的接口
3.再次,我们对客户程序进行有效的区分,并对应接口进行变化,比如客户程序又乱又杂,此时我们就需要对其进行分离,随着客户程序的分离,其对应的接口也随之变化
6.迪米特法则
迪米特法则主要分为两大类
第一类,狭义的迪米特法则 如果两个类不必彼此直接通信,那么这两个类就不应当发送直接的相互调用,如果其中一个类需要调用另一个雷的方法的话可以通过第三者转发这个调用
第二类,广义的迪米特法则,一个模块设计的好坏,一个重要的标识就是该模块在多大的程度上将自己的数据实现的有关细节隐藏起来。
如何实现迪米特法则
1.设计者对类进行分类设计时,需要创建低耦合的类层次关系,使类之间的耦合度越来越低,重而达到高重用的效果
2.设计者对类进行构造时,每个类之间都需要降低成员之间的访问程度,特别是实体类,我们需要尽量的降低它的访问权限,我们可以开发的取值和赋值的方法供外界访问自己的属性,
都是如果把实体类定义成public那么客户端就有可能会调用这个类,此时,实体类呗删除,则会导致一些客户程序出错。
3.尽量把一些类设计成不变的类,以便功能的实现
4.注意与依赖倒换原则相结合,因为,过度使用迪米特法则会产生大量的中间类,这将导致系统维护变得复杂,此时使用依赖倒换原则来解决,通过调用方和被调用方之间增加一个抽象层,
被调用方在遵循抽象层的前提下就可以自由变化,此时抽象层成了调用方的朋友了。
7.组合/聚合复用原则
该远程就是在一个新的对象里面使用一些已有的对象,使之承兑新对象的一部分,新的对象通过这些对象的委派达到复用已有的功能目的
实现开闭原则的核心是抽象,将变化部分和不变化部分区分开来,这有利于功能的扩展
一句话概括就是,对扩展是开发的对修改是关闭的.
在实际的编码当中虽然不能做到百分之百按照开闭原则来,但是朝着这个目标去编码。
个人认为开闭原则从软件的系统的角度来说:软件系统的个个功能组件,如菜单、模块、类、以及功能等等,应该在不修改原有代码的基础上增加新的功能.同时对于经常发生变化有关的值,
可以进行封装.至于开闭原则中的开始对组件的功能扩展是开发的,是允许对其功能扩展的。开闭原则的闭,可以认为是原有代码的修改是关闭的。既不动原有代码,又能增加新的组件功能。
简而言之我们可以把开闭原则理解成——————根据需求随意添加新的类,但是不需要修改原有的代码
2。单一职能原则
1.防止相同类型的职责分离到不同的类中,即我们需要提高代码的可重用性
2.同一个类无需编制多余的职责,即用情专一继承了中国男人的传统美德
打个简单的比喻,酒店的厨师,他只负责做菜,而不负责送菜,洗碗的阿姨只负责洗好碗,等等。。
优点:
1.有助于清楚的希求设计与编码的思路
2.有助于简化维护,编码,测试的流程
3.将复杂的问题简单化,有助于代码的重用
4.职责时间消除耦合,有利于系统的扩展。
实现单一职能原则——————类的大小要适中,不能太小会疲于维护.如 添加 修改 删除,如果按照单一原则可以将其分为3个类,其实这个时候可以将这些都放到操作类当中
3.里氏替换原则
我们在涉及类的继承设计的时候可以从"父类不能替换子类,而子类型可以替换基类",的思路引导下,进行里式代换的原则的实现。
首先正确地进行继承设计,所有基类的方法都要在其子类中得到实现或者重写,并且子类不能写出与业务无关的多余方法
其次最优的继承层次设计,当其他应用类调用业务功能类时,应该调用其业务功能的基类而不应该直接去调用业务功能的子类;
里氏替换原则在策略模式,合成模式,代理模式,都有充分的体现
4.依赖倒换原则
其定义有两点;
1.高层不应该依赖于底层,两者都应该依赖于抽象,抽象不应该依赖于细节,细节应当依赖于抽象.简而言之,就是我们在设计系统运用依赖倒换原则的时候,
需要运用抽象来进行分析不要一开始就关注细节。
2.针对接口编程,不要针对实现编程,我们可以运用依赖倒换原则,可以通过接口来进行类,变量,参数,方法等的声明,并且禁止用实现类去做以上的声明。
如何去实现依赖倒换原则
1.从实现类与抽象的角度进行分析,我们在运用具体实现去集成抽象类时,需要保证引用基类之处可愿意修改成其子类
2.从层次的关系进行分析,需要定义清晰的层次关系,使每个层次通过接口的方式进行.
3.从对象的构造角度进行分析,如果创建的是动态对象,使用依赖倒换原则。如果创建的是一些静态的具体类并且变化率很低,则我们无需再创建其类去集成,以规避维护多余代码的风险。
5.接口隔离原则
其定义有三点
1.不应该强迫客户(其子类)依赖于它们不用的方法
2.一个雷对另一个类的依赖性应当是建立在最小的接口上
3.要将接口理解成角色
接口的隔离原则可以从以下几个角度去思考
1.首先从业务逻辑的角度去考虑接口,我们可以把某类功能也没设计成接口,如影片中的正角,反角可以设计成接口,然后正角的演员可以当成是实现类。
2.其次根据场合和调用者的情况消除无关的方法,只提供同类型角色的接口
3.再次,我们对客户程序进行有效的区分,并对应接口进行变化,比如客户程序又乱又杂,此时我们就需要对其进行分离,随着客户程序的分离,其对应的接口也随之变化
6.迪米特法则
迪米特法则主要分为两大类
第一类,狭义的迪米特法则 如果两个类不必彼此直接通信,那么这两个类就不应当发送直接的相互调用,如果其中一个类需要调用另一个雷的方法的话可以通过第三者转发这个调用
第二类,广义的迪米特法则,一个模块设计的好坏,一个重要的标识就是该模块在多大的程度上将自己的数据实现的有关细节隐藏起来。
如何实现迪米特法则
1.设计者对类进行分类设计时,需要创建低耦合的类层次关系,使类之间的耦合度越来越低,重而达到高重用的效果
2.设计者对类进行构造时,每个类之间都需要降低成员之间的访问程度,特别是实体类,我们需要尽量的降低它的访问权限,我们可以开发的取值和赋值的方法供外界访问自己的属性,
都是如果把实体类定义成public那么客户端就有可能会调用这个类,此时,实体类呗删除,则会导致一些客户程序出错。
3.尽量把一些类设计成不变的类,以便功能的实现
4.注意与依赖倒换原则相结合,因为,过度使用迪米特法则会产生大量的中间类,这将导致系统维护变得复杂,此时使用依赖倒换原则来解决,通过调用方和被调用方之间增加一个抽象层,
被调用方在遵循抽象层的前提下就可以自由变化,此时抽象层成了调用方的朋友了。
7.组合/聚合复用原则
该远程就是在一个新的对象里面使用一些已有的对象,使之承兑新对象的一部分,新的对象通过这些对象的委派达到复用已有的功能目的
其实这里最终的区别就是区分has-a和is-a的区别,相对于复合和聚合