前言设计模式的目的
编写程序过程中,软件工程师们面临着众多挑战,其中,低耦合性(功能和功能之间低耦合)、高内聚性(模块内部是十分紧密的)、可扩展性以及可维护性、灵活性(增加新功能十分方便)、重用性(相同的功能,代码无需重复编写),可靠性(增加新的功能后,原来的功能不受影响)都是必须要考虑的因素,所以设计模式是为了让程序更可靠,更灵活,更具有面向对象的精髓
设计模式七大原则
单一职责原则
对类来说,即一个类只负责一个职责,比如我们之前写过的studentMapper他就知识负责学生的增删改查,这就是一个单一职责,如果说studentMapper还要去负责老师的信息管理,这就违背的单一职责原则,这个时候我们需要把studentMapper分成A类和B类,A去管理学生,B去管理老师。
package com.rlw.principle.singleresponsibility;
public class SingleResponsibility {
public static void main(String[] args) {
Tiger tiger = new Tiger();
tiger.eat("母老虎");
tiger.eat("菜包子");
tiger.eat("菜团子");
tiger.eat("菜卷子");
}
}
class Tiger {
public void eat(String tiger) {
System.out.println(tiger + "在吃人!!!");
}
}
此时已经违反了单一职责原则,母老虎可以吃人没问题,但是菜包子什么的就违反了单一职责原则。
改良2::单一职责原则模式:但是软件花销比较大,即不仅需要修改很多个类,还要修改主方法(客户端)
package com.rlw.principle.singleresponsibility;
public class SingleResponsibility {
public static void main(String[] args) {
Tiger tiger = new Tiger();
tiger.eat("母老虎");
CaiBaoZi caiBaoZi = new CaiBaoZi();
caiBaoZi.eat("菜包子");
CaiTuanZi caiTuanZi = new CaiTuanZi();
caiTuanZi.eat("菜团子");
CaiJuanZi caiJuanZi = new CaiJuanZi();
caiJuanZi.eat("菜卷子");
}
}
class Tiger {
public void eat(String tiger) {
System.out.println(tiger + "在吃人!!!");
}
}
class CaiBaoZi{
public void eat(String cai){
System.out.println(cai + "在吃火锅!!!");
}
}
class CaiTuanZi{
public void eat(String cai){
System.out.println(cai + "菜团子在喝可乐!!!");
}
}
class CaiJuanZi{
public void eat(String cai){
System.out.println(cai + "菜卷子在想吃鸡架!!");
}
}
改良3::这类虽然没有在类的级别上实现单一职责原则,但是在方法级别上仍然遵守单一职责原则
package com.rlw.principle.singleresponsibility;
public class SingleResponsibility {
public static void main(String[] args) {
Tiger tiger = new Tiger();
tiger.tigerEat("母老虎");
tiger.caiBaoZiEat("菜包子");
tiger.caiTuanZiEat("菜团子");
tiger.caiJuanZiEat("菜卷子");
}
}
class Tiger {
public void tigerEat(String tiger) {
System.out.println(tiger + "在吃人!!!");
}
public void caiBaoZiEat(String tiger) {
System.out.println(tiger + "在吃火锅!!!");
}
public void caiTuanZiEat(String tiger) {
System.out.println(tiger + "在喝可乐!!!");
}
public void caiJuanZiEat(String tiger) {
System.out.println(tiger + "在想吃鸡架!!!");
}
}
//补充一点,改良3版本如果方法及其多,那我们还是要使用改良2的办法分多个类进行拆分
总结:单一职责原则各行其职!!!!
接口隔离原则
一个类不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小接口上
package com.rlw.principle.segregation;
public class Segregation1 {
public static void main(String[] args) {
}
}
interface Interface1{
void operation1();
void operation2();
void operation3();
void operation4();
void operation5();
}
class B implements Interface1{
@Override
public void operation1() {
System.out.println("B 实现了 operation1");
}
@Override
public void operation2() {
System.out.println("B 实现了 operation2");
}
@Override
public void operation3() {
System.out.println("B 实现了 operation3");
}
@Override
public void operation4() {
System.out.println("B 实现了 operation4");
}
@Override
public void operation5() {
System.out.println("B 实现了 operation5");
}
}
class D implements Interface1{
@Override
public void operation1() {
System.out.println("D 实现了 operation1");
}
@Override
public void operation2() {
System.out.println("D 实现了 operation2");
}
@Override
public void operation3() {
System.out.println("D 实现了 operation3");
}
@Override
public void operation4() {
System.out.println("D 实现了 operation4");
}
@Override
public void operation5() {
System.out.println("D 实现了 operation5");
}
}
class A{//A类通过接口Interface1依赖B类,但是只会用到1,2,3方法
public void depand1(Interface1 i){
i.operation1();
}
public void depand2(Interface1 i){
i.operation2();
}
public void depand3(Interface1 i){
i.operation3();
}
}
class C{//C类通过接口Interface1依赖B类,但是只会用到1,2,3方法
public void depand1(Interface1 i){
i.operation1();
}
public void depand4(Interface1 i){
i.operation4();
}
public void depand5(Interface1 i){
i.operation5();
}
}
一个类对另一个类的依赖应该建立在最小接口上
以上代码类A通过接口Interface1依赖B,类C通过接口Interface1依赖D,如果接口Interface1对于类A和类C来说不是最小接口,那么类B和类D必须去实现他们不需要的方法。
按照隔离原则应当这样处理:将接口Interface1拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则
接口Interface1中出现的方法,根据实际情况拆分为三个接口
package com.rlw.principle.segregation;
public class Segregation1 {
public static void main(String[] args) {
A a = new A();
a.depand1(new B()); //A类通过接口去依赖B
a.depand2(new B());
a.depand3(new B());
C c = new C();
c.depand1(new D());//C类通过接口去依赖D
c.depand4(new D());
c.depand5(new D());
}
}
interface Interface1{
void operation1();
}
interface Interface2{
void operation2();
void operation3();
}
interface Interface3{
void operation4();
void operation5();
}
class B implements Interface1,Interface2{
@Override
public void operation1() {
System.out.println("B 实现了 operation1");
}
@Override
public void operation2() {
System.out.println("B 实现了 operation2");
}
@Override
public void operation3() {
System.out.println("B 实现了 operation3");
}
}
class D implements Interface1,Interface3{
@Override
public void operation1() {
System.out.println("D 实现了 operation1");
}
@Override
public void operation4() {
System.out.println("D 实现了 operation4");
}
@Override
public void operation5() {
System.out.println("D 实现了 operation5");
}
}
class A{//A类通过接口Interface1依赖B类,但是只会用到1,2,3方法
public void depand1(Interface1 i){
i.operation1();
}
public void depand2(Interface2 i){
i.operation2();
}
public void depand3(Interface2 i){
i.operation3();
}
}
class C{//C类通过接口Interface1依赖B类,但是只会用到1,2,3方法
public void depand1(Interface1 i){
i.operation1();
}
public void depand4(Interface3 i){
i.operation4();
}
public void depand5(Interface3 i){
i.operation5();
}
}
总结:类通过接口最小依赖另一个类类
依赖倒转原则
高层模块不应依赖低层模块,两个模块都应该以来抽象(接口或抽象类)
抽象不应该依赖细节,细节应该依赖抽象
依赖倒转的中心思想是面向接口编程
依赖倒转原则是基于这样的设计理念,相当于细节的多变性,抽象的东西要稳定。以抽象为基础搭建的架构比细节为基础的架构要稳定的多。在java中,抽象指的是接口或抽象类,细节可以理解为具体的实现类。
使用接口或者抽象类的目的是指定好规范,而不涉及任何具体的操作,把展现西接的任务交给他们的实现类去完成(接口和抽象类的价值在设计上)
反例:
完成Person接收消息
分析
如果我们获取的对象不是Email,而是短信,微信等等,则必须新增类,同时Person也要增加相应的接收方法
package com.rlw.principle.inversion;
public class DependecyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
}
}
class Email {
public String sendEmail() {
return "你好,这里是Email";
}
}
class Person {
public void receive(Email email) {
System.out.println(email.sendEmail());
}
}
依赖倒转例子
解决思路,根据依赖倒转原则,引入一个抽象的接口IReceiver表示接收者,这样erson类与接口IReceiver发生依赖
因为Eamil,微信等等属于接收的范围,他们各自实现IReceiver接口就行,这样就符合依赖倒转原则
package com.rlw.principle.inversion;
public class DependecyInversion {
public static void main(String[] args) {
Person person = new Person();
person.receive(new Email());
person.receive(new WeiXin());
}
}
interface IRecever{
public String send();
}
class Email implements IRecever{
public String send() {
return "你好,这里是Email";
}
}
class WeiXin implements IRecever{
public String send() {
return "你好,这里是微信";
}
}
class Person {
public void receive(IRecever iRecever) {
System.out.println(iRecever.send());
}
}
可以发现如果想要不使用接口实现就会很麻烦,需要在Person中重新写方法。
三个小例子
接口传递依赖
package com.rlw.principle.inversion;
//通过接口传递实现依赖
public class Demo {
public static void main(String[] args) {
XiaoMi xiaoMi = new XiaoMi();
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.open(xiaoMi);
}
}
interface IOpenAndClose{
public void open(ITV itv);
}
interface ITV{
public void play();
}
class XiaoMi implements ITV{
@Override
public void play() {
System.out.println("小爱同学!!!");
}
}
class OpenAndClose implements IOpenAndClose{
@Override
public void open(ITV itv) {
itv.play();
}
}
构造器传递依赖
package com.rlw.principle.inversion;
//通过g构造器传递实现依赖
public class Demo2 {
public static void main(String[] args) {
XiaoMi xiaoMi = new XiaoMi();
OpenAndClose openAndClose = new OpenAndClose(xiaoMi);
openAndClose.open();
}
}
interface IOpenAndClose{
public void open();
}
interface ITV{
public void play();
}
class XiaoMi implements ITV{
@Override
public void play() {
System.out.println("小爱同学!!!");
}
}
class OpenAndClose implements IOpenAndClose{
public ITV itv;
public OpenAndClose(ITV itv) {//构造器
this.itv = itv;
}
@Override
public void open() {
this.itv.play();
}
}
setter方式传递
package com.rlw.principle.inversion;
//通过g构造器传递实现依赖
public class Demo3 {
public static void main(String[] args) {
XiaoMi xiaoMi = new XiaoMi();
OpenAndClose openAndClose = new OpenAndClose();
openAndClose.setTv(xiaoMi);
openAndClose.open();
}
}
interface IOpenAndClose {
public void open();
public void setTv(ITV itv);
}
interface ITV {
public void play();
}
class XiaoMi implements ITV {
@Override
public void play() {
System.out.println("小爱同学!!!");
}
}
class OpenAndClose implements IOpenAndClose {
private ITV itv;
@Override
public void setTv(ITV itv) {
this.itv = itv;
}
@Override
public void open() {
this.itv.play();
}
}
里氏替换原则
OO中的继承性的思考和说明:
继承包含这样一层含义:父类中凡是已经实现好的方法,实际上是在设定规范和契约,虽然他不强制要求所有的子类必须遵守,但是如果子类对这些已经实现的方法任意修改,就会对整个继承体系造成破坏
继承在给程序设计带来便利的同时,也带来了弊端,比如使用继承会给程序带来侵入性,程序的可移植性降低,增加对象间的耦合性,如果一个类背其他的类所继承,则当这个类需要修改时,必须考虑到所有的子类,并且父类修改后,所有涉及到子类的功能都有可能产生故障
小结:在编程中正确的使用继承=>里氏替换原则;所有引用父类的地方必须能清晰的使用其子类对象;在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类方法;里氏替换原则告诉我们,继承实际上让两个类耦合性增强了,在适当的情况下,可以通过聚合,组合,依赖来解决问题
package com.rlw.principle.liskov;
public class LiskovDemo {
public static void main(String[] args) {
A a = new A();
System.out.println(a.func1(1, 2));
//---------------
B b = new B();
System.out.println(b.func2(1, 2));//想要的结果应该是1-2+9,但事实上我们重写了func1,这个重写可能是不经意间的,父类中的function1可能是隐式的,子类中的function1可能是无意的。
}
}
class A{
public int func1(int a ,int b){
return (a-b);
}
}
class B extends A{
@Override
public int func1(int a, int b) {//无意重写
return (a+b);
}
public int func2(int a, int b) {
return func1(a,b)+9;
}
}
我们发现原来运行正常的相减功能发生了错误,原因就是类B无意中重写了父类的方法,造成原有的功能出现了错误。在实际开发中,我们常常会通过重写父类的方法完成功能,这样写方便,但整个继承体系复用性比较差,特别是运行多态比较频繁的时候
通常的做法是:将原来的父类和子类都继承一个更通俗的父类,原有的继承关系去掉,采用依赖,聚合,组合等关系代替
改进例子:
package com.rlw.principle.liskov;
public class LiskovDemo {
public static void main(String[] args) {
A a = new A();
System.out.println(a.func1(1, 2));
//---------------
B b = new B();
System.out.println(b.func2(1, 2));//想要的结果应该是1-2+9,但事实上我们重写了func1,这个重写可能是不经意间的,父类中的function1可能是隐式的,子类中的function1可能是无意的。
//仍然使用a中的方法,此时的耦合性降低了,*****其实这就像我们常些的三层结构一个意思****
B b1 = new B();
System.out.println(b1.func3(1,2));
}
}
class Base{
//把更加基础的方法写道Base类中,Base是一个特别基础的类不常更改
}
class A extends Base{
public int func1(int a ,int b){
return (a-b);
}
}
class B extends Base{
private A a = new A();
//因为B类不再继承A类,因此调用者不会再认为func1是减法了,调动功能会很明确
public int func1(int a, int b) {//无意重写
return (a+b);
}
public int func2(int a, int b) {
return func1(a,b)+9;
}
public int func3(int a, int b){
return this.a.func1(a,b);
}
}
开闭原则
开闭原则是编程中最基础,最重要的设计原则
一个软件实体加类,模块和函数应该对扩展开放,对修改关闭。用抽象构建框架,用实现扩展细节
当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化
编程中遵循其他原则,以及使用设计模式的目的就是遵循开闭原则
package com.rlw.principle.ocp;
public class Ocp {
public static void main(String[] args) {
GraphicEditor graphicEditor =new GraphicEditor();
graphicEditor.drawShape(new Circle());
graphicEditor.drawShape(new Rectangle());
}
}
//这是一个用于画图的类***使用方***
class GraphicEditor{
//接收Shape对象,然后根据tupe绘制不同的图形
public void drawShape(Shape shape){
if (shape.type==1){
drawRectangle(shape);
}else if (shape.type==2){
drawCircle(shape);
}
}
public void drawRectangle(Shape shape){
System.out.println("画矩形");
}public void drawCircle(Shape shape){
System.out.println("画圆形");
}
}
class Shape{
int type;
}
class Rectangle extends Shape{
Rectangle(){
super.type=1;
}
}
class Circle extends Shape{
Circle(){
super.type=2;
}
}
以上代码分析:
有点好理解,减低易操作
缺点是违背了和寂寞时的ocp,即对扩展开放对修改关闭,当我们新增一个功能的时候,加入我想新增一个绘制三角形的功能,需要新增一个class,GraphicEditor中需要新增方法,方法中需要改代码;
改进例子:
package com.rlw.principle.ocp.impro;
public class OcpImpro {
public static void main(String[] args) {
GraphicEditor graphicEditor =new GraphicEditor();
graphicEditor.drawShape(new Circle());
graphicEditor.drawShape(new Rectangle());
}
}
//这是一个用于画图的类***使用方***
class GraphicEditor{
//接收Shape对象,然后根据tupe绘制不同的图形
public void drawShape(Shape shape){
shape.draw();
}
}
abstract class Shape{
int type;
public abstract void draw();//抽象方法
}
class Rectangle extends Shape{
Rectangle(){
super.type=1;
}
@Override
public void draw() {
System.out.println("绘制矩形");
}
}
class Circle extends Shape{
Circle(){
super.type=2;
}
@Override
public void draw() {
System.out.println("绘制圆形");
}
}
小结:A抽象类被B,C去继承分别实现draw抽象方法,再GraphicEditor方法中以抽象类接收B类C类来调用具体实现,接到的是B就找B重写的方法,接到的是C就找C重写的方法,这样新增功能很容易维护。
迪米特法则
一个对象应该对其它对象保持最少知道原则
类与类关系越密切,耦合度越大
迪米特法则也叫最少知道原则,即一个类对自己依赖的类知道的越少越好。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外部除了提供的public方法,不对外泄露任何信息
迪米特法则还有个更简单的定义:只与直接的朋友通信
直接的朋友:每个对象都会与其他对象有耦合关系,只要两个对象之间有偶哦和关系,我们就说这两个对象之间是朋友关系。耦合的方式有很多,依赖,关联,组合,聚合等。其中,我们称出现成员变量,方法参数,方法返回值中的类为直接朋友,儿出现在局部变量中的类不是直接朋友(在A类的test方法中存在B b = new B)也就是说,陌生的类最好不要以局部变量的形式出现在类的内部。6.50