输入法网站设计,自建站有哪些站点,辽宁建设工程信息网怎么获取招标文件,wordpress图片分页插件一、介绍 在软件工程中#xff0c;设计模式#xff08;design pattern#xff09;是对软件设计中普遍存在#xff08;反复出现#xff09;的各种问题#xff0c;提出的解决方案。我们希望我们的软件能够实现复用性、高稳定性、扩展性、维护性、代码重用性#xff0c;所以…一、介绍 在软件工程中设计模式design pattern是对软件设计中普遍存在反复出现的各种问题提出的解决方案。我们希望我们的软件能够实现复用性、高稳定性、扩展性、维护性、代码重用性所以出现了设计模式的概念。
设计模式常用的七大原则 1单一职责原则 2接口隔离原则 3依赖倒转原则 4里氏替换原则 5开闭原则ocp 6迪米特法则 7合成复用原则 设计模式的目的 1代码重用性即相同功能的代码不用多次编写 2可读性即编程规范性便于其他程序员的阅读和理解 3可扩展性即需要增加新的功能时非常方便 4可靠性即增加新的功能后对原来的功能没有影响 5使程序呈现高内聚、低耦合的特性 二、单一职责原则 对一个类来说一个类应该只负责一项职责。 1降低类的复杂度一个类只负责一项职责 2提高类的可读性可维护性 3降低变更引起的风险 4通常情况下我们应当遵守单一职责原则只有逻辑足够简答才能在代码级违反单一职责原则只有类中的方法数量足够少才可以在方法级别保持单一职责原则。 三、接口隔离原则 客户端不应该依赖它不需要的接口。即一个类对另一个类的依赖应该建立在最小的接口上。
改进前 改进后 四、依赖倒转原则 1高层模块不应该依赖低层模块二者都应该依赖其抽象 2抽象不应该依赖细节细节应该依赖抽象 3依赖倒转倒置的中心思想是面相接口编程 4依赖倒转原则是基于这样的设计理念相对于细节的多变性抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定得多。在java中抽象就是接口或抽象类细节就是具体的实现类 5使用接口或抽象类的目的是制定好规范而不涉及任何具体的操作把展示细节的任务交给它们的实现类去完成。 改进前
//方式1实现Person接收消息的功能
class Person {public void receive(Email email) {System.out.println(email.getInfo());}
} 问题如果我们获取的对方改变Person也要增加相应的接受方法解决思路引入一个抽象的接口IReceiver表示接受者这样Person类与接口IReceiver发生依赖。其他实现都属于接收的范畴只需各自实现IReceiver接口就可以。这样就符合依赖倒转原则 改进后对接口进行依赖稳定性提高
//方式2//定义接口
interface IReceiver {public String getInfo();
}class Email implements IReceiver {public String getInfo() {return 电子邮件信息hello, world;}
}class Person {public void receive(IReceiver receiver) {System.out.println(receiver.getInfo());}
}public class DependencyReceiver {public static void main(String[] args) {//客户端无需改变Person person new Person();person.receive(new Email());}
}
依赖传递的三种方式
依赖传递有三种方式这里只写调用方法ChangHong changHong new ChangHong();1通过接口传递实现依赖
OpenAndClose openAndClose new OpenAndClose();
openAndClose.open(changHong);2通过构造器进行依赖传递
OpenAndClose openAndClose new OpenAndClose(changHong);
openAndClose.open();3通过setter方法传递
OpenAndClose openAndClose new OpenAndClose();
openAndClose.setTv(changHong);
openAndClose.open();五、里氏替换原则 继承性说明 1父类中凡是实现好的方法实际上是某种规范和契约虽然不强制所有子类必须遵守但如果子类对这些已实现的方法进行任意修改就会对整个继承体系造成破坏。 2继承的弊端使用继承会给程序带来侵入性程序的可移植性降低增加对象间的耦合性。如果一个类被其他类继承当这个类需要修改时必须考虑所有子类。且父类修改后所有涉及到子类的功能都可能发生故障。 3为了解决这一问题我们提出里氏替换原则 里氏替换原则 1如果每个类型为T1的对象O1都有类型为T2的对象O2使T1定义的所有程序P在所有对象O1被替换成O2时程序P没有任何变化。那么T2是T1的子类型。也就是说所有引用基类的地方必须能透明的使用其子类的对象。 2在使用继承时子类尽量不要重写父类的方法。 比如说A类中有m1、m2、m3三个方法B类继承A类且重写了A类的所有方法这样就无法做到透明化。 对此我们可以让B类和A类共同继承一个更加基础的base类使AB类耦合性降低将AB类的公共方法提高base类中。 六、开闭原则 介绍 1开闭原则是编程中最基础、最重要的设计原则。 2一个软件实体如类、模块和函数应该对扩展开放对提供方对修改关闭对使用方。用抽象构建框架用实现扩展细节。 3当软件需要变化时尽量通过扩展软件实体的行为来实现变化而不是通过修改已有的代码来实现变化。 4编程中遵循其他原则以及使用设计模式的目的就是遵循开闭原则。 改进前
//用于绘图的类
class GraphicEditor {//接受Shape对象根据type绘制不同的图形public void drawShape(Shape s) {if(s.m_type 1) drawRectangle(s);else if(s.m_type 2) drawCircle(s);}public void drawRectangle(Shape s) {System.out.println(绘制矩形);}public void drawCircle(Shape s) {System.out.println(绘制圆形);}
}//Shape类基类
class Shape {int m_type;
}class Rectangle extends Shape {Rectangle(){super.m_type1;}
}class Circle extends Shape {Circle(){super.m_type2;}
}public classOcp {public static void main(String[] args) {//存在的问题GraphicEditor graphicEditor new GraphicEditor();graphicEditor.drawShape(new Rectangle());graphicEditor.drawShape(new Circle());}
}
存在的问题 违反了设计模式的OCP原则即对扩展开放对修改关闭。即当我们给类增加新功能的时候尽量不修改代码或者尽可能少修改代码。 思路把shape类做成抽象类并提供一个抽象的draw方法让子类去实现。这样当我们有新图形时只需要让新的图形类继承shape、并实现draw方法。使用方的代码就不需要修改。 改进后
//用于绘图的类
class GraphicEditor {//接受Shape对象根据type绘制不同的图形public void drawShape(Shape s) {s.draw();}
}//Shape类基类
abstract class Shape {int m_type;public abstract void draw();
}class Rectangle extends Shape {Overridepublic void draw() {System.out.println(绘制矩形);}
}class Circle extends Shape {Overridepublic void draw() {System.out.println(绘制圆形);}
}public classOcp {public static void main(String[] args) {//存在的问题GraphicEditor graphicEditor new GraphicEditor();graphicEditor.drawShape(new Rectangle());graphicEditor.drawShape(new Circle());}
} 七、迪米特法则 基本介绍 1一个对象应该对其他对象保持最少的了解 2类与类的关系越密切耦合度越大 3迪米特法则又叫最少知道原则即一个类对自己依赖的类知道的越少越好。对于被依赖的类不管多么复杂都尽量将逻辑封装在类的内部。对外除了提供的public方法不对外泄露任何信息。所以陌生的类最好不要以局部变量的形式出现在类的内部。 注意事项 1迪米特法则的核心是降低类之间的耦合。 2由于每个类都减少了不必要的依赖因此迪米特法则只是要求降低类间对象间耦合关系并不是要求完全没有依赖关系。 八、合成复用原则
尽量使用合成、聚合的方式而不是使用继承。
从 is a 变成 has a 九、总结
1找出应用中可能需要变化之处把它们独立出来不要和那些不需要变化的代码混在一起。
2针对接口编程而不是针对实现编程。
3为了交互对象之间的松耦合设计而努力
