java设计模式

2017-12-26  本文已影响0人  六_六

1.单一职责原则

定义:就一个类而言,应该仅有一个引起它变化的原因。这句话的意思是说:我们不要让一个类承担过多的职责,如果一个类承担的职责过多,就等于把这些职责全部耦合子一起。一个职责的变化可能会削弱活着抑制这个类完成其他的职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭到破环。比如我经常看到一些android开发在Activity中写网络数据处理逻辑,如果有listview列表的话也写在activity类中,问他们为什么这样写除了好找代码也没啥理由了,如果把它们拆分大别的类中不是更好找,更清晰了吗。如果acticity过于臃肿行数过多,显然不是什么好事,如果列表adpater和网络数据有变化,我们都要在这个activity来修改,就会导致这个activity的变化的原因太多,我们在版本维护的时候也会比较头疼。也就严重违背了定义“就一个类而言。应该仅有一个引起它变化的原因”。

2.开放封闭原则

定义:类、模块、函数等等等应该是可以拓展的,但是不可修改,开放封闭有两个含义,一个对于拓展是开放的,一个对于修改是封闭的。对于开发来说需求肯定是要变化的,但是新需求一来,我们就要把类重新改一遍这显然是令人头疼的,所以我们设计程序时面对需求的改变要尽可能的保证相对的稳定,尽量用新代码实现拓展来修改需求,而不是通过修改原来的代码来实现。假设我们要实现一个列表,一开始只有查询的功能,这时产品需要增加添加功能,过几天又要新增删除功能,大多人都是写一个方法通过传入不同的值来控制方法实现不同的功能,但是如果又要新增功能我们还的修改我们的方法。用开发封闭原则解决就是增加一个抽象的功能类,让增加和删除和查询作为这个抽象类的字类,这样如果我们在添加功能,你就会发现我们不需要修改原有的类,只需要添加一个功能类的字类实现功能类的方法就可以了。

3.里氏替换原则

定义:所有引用基类(父类)的地方必须能透明的使用其子类的对象,里氏替换原则告诉我们,在软件中将一个基类对象替换成它的字类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个字类对象的话,那么它不一定能够使用基类对象,里氏替换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用字类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时在确定其子类类型,用子类对象来替换父类对象。在使用时需要注意一下几个地方:

4.依赖倒置原则

定义:高层模块不应该依赖底层模块,两个都应该依赖于抽象。抽象不应该依赖细节,细节应该依赖于抽象。在java中,抽象就是指接口或者抽象类,两者都是不能直接被实列化的。细节就是实现类,实现接口或者继承抽象类而产出的就是细节,也就是可以加上一个关键字new产生的对象,高层模块就是调用端,底层模块就是具体实现类。依赖倒置原则在java中的表现就是:模块间通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的。如果与类直接依赖细节,那么就会直接耦合,那么修改时,就会同时修改依赖者代码,这样就限制了可扩展性。

5.迪米特原则

定义:一个软件实体应当尽可能少得与其他实体发生相互作用。也称为最少知识原则。如果一个系统符合迪米特原则,那么其中某一个模块发生修改时,就会尽量少的影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特原则要求限制团建实体之间通信的宽度和深度。迪米特法则可降低系统的耦合毒,使得类与类保持松散的耦合关系。迪米特原则要求我们在设计系统时,应该尽量减少对象之前的交互,如果两个对象之间不必彼此通信,那么这两个对象就不应当发生任何的相互作用,如果其中一个对象需要调用另外一个对象的方法时,可以通过第三者来转发这个调用,简言之,就是通过引入一个合理的第三者来降低现有对象之间的耦合度,在将迪米特原则运用到系统设计中时,要注意以下几点:

6.接口隔离原则

定义:一个类对另一个类的依赖应该建立在最小的接口上,建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量小,也就是说,我们要为各个类建立专用的接口,而不要试图去建立一个庞大的接口供所有依赖它的类去调用。采用接口隔离原则对接口进行约束时要注意以下几点:

上一篇 下一篇

猜你喜欢

热点阅读