Java设计模式 Java设计模式常用原则解析
懒惰的星期六 人气:01.单一职责原则 每一个类负责一个职责(一个类只有一个方法)
2.里氏替换原则 所有引用基类的地方都能透明的使用其子类的对象。
问题来了:
比如原来
class A{ fun();//完成P1功能 }
现在需要添加新功能
class B extends A{//A的子类B实现了fun的功能) fun();完成功能为P(原来的P1功能加上新增的P2功能) }
则,在子类B完成新功能P2的时候可能会导致原有功能P1发生故障
解决办法
当使用继承的时候,除了添加新的方法来完成新功能P2之外,尽量不要重写父类A的方法,也尽量不要重载父类A 的方法
3.依赖倒置原则(核心思想,面向接口编程)
定义:高层模块不应该以来底层模块,二者都应该依赖其抽象;抽象不应该依赖细节,细节应该依赖抽象;
问题:
类A(高层模块)直接依赖B(低层模块)
eg:class A{ public void fun(B b){}; }
现在想要把类A的依赖改为C,则必须修改类A的代码为
eg:class A{ public void fun(C c){}; }
解决办法:
类B和类C都实现接口Interface D;
类A依赖接口D
eg:class A{ public void fun(D d){}; }
这样在使用类A的fun方法时可以这样使用fun(new B());或者fun(new C());
4.接口隔离原则
将臃肿的接口才氛围独立的几个接口,这样子类在实现该接口时就不必要实现臃肿接口的所有的抽象方法
5.迪米特法则(最少知道法则)
降低类与类之间的耦合度,从而减少当一个类改变时对另一个类造成的影响。
简单来说,就是一个类对自己以来的类知道的越少越好。对于被以来的类,无论逻辑多么复杂,尽可能的将逻辑封装在类的内部,对外提供一个public的方法就行了。
更简单的定义:至于直接的朋友(称出现成员变量、方法参数、方法返回值中的类为直接朋友,出现在局部变量中的类不是直接的朋友)进行通信。
(依赖的三种方式,方法参数,局部变量-方法内的变量,静态变量-方法中调用某个类的静态方法)
6.开闭原则
一个软件实体类、模块、和函数应该对扩展开放,对修改关闭。
问题:当软件升级维护时,队友俺有代码进行修改,可能会给旧代码引入错误。
解决办法:当软件需要变化时,尽可能通过扩展软件实体的行为来实现变化,儿不是通过修改已有的代码来实现变化。
加载全部内容