什么是wordpress网站vi设计整套

当前位置： 首页 > news >正文

什么是wordpress网站,vi设计整套,关键词如何优化排名,微信公众号 链接微网站​更多内容#xff0c;前往 IT-BLOG ​设计模式的目的是为了让程序#xff0c;具有更好的代码重用性、可读性#xff08;编程规范性#xff0c;便于后期维护和理解#xff09;、可扩展性#xff08;当需要增加新需求时#xff0c;非常方便#xff09;、可靠性#xf…​更多内容前往 IT-BLOG ​设计模式的目的是为了让程序具有更好的代码重用性、可读性编程规范性便于后期维护和理解、可扩展性当需要增加新需求时非常方便、可靠性增加新功能后对原功能么有影响、使程序呈现高内聚低耦合的特性。设计模式包含了面向对象的精髓“懂了设计模式就懂得了面向对象分析和设计OOA/D的核心” 一、单一职责原则 单一职责原则SRPSingle responsibility principle又称为单一功能原则 它规定一个类应该只负责一项职责。 单一职责原则注意事项和细节 1、降低类的复杂度一个类只负责一项职责。 2、提高类的可读性可维护性。 3、降低变更引起的风险。 4、通常情况下我们应当遵守单一职责原则只有当逻辑足够简单时才可以在代码级别违反单一职责原则只有类中方法足够少可以在方法级别保持单一职责原则。 二、接口隔离原则 接口隔离原则Interface Segregation PrincipleISP的定义 客户端不应该依赖它不需要的接口类类之间的依赖关系应该建立在最小的接口上。一句话就是实现接口的类中有多余的方法时需要将接口进行拆分。 接口隔离原则的规范 1、使用接口隔离原则前首先需要满足单一职责原则。 2、接口需要高内聚也就是提高接口、类、模块的处理能力少对外发布public的方法。 3、定制服务就是单独为一个个体提供优良的服务简单来说就是拆分接口对特定接口进行定制。 4、接口设计是有限度的接口的设计粒度越小系统越灵活但是值得注意不能过小否则变成字节码编程。 接口隔离解决的问题如下实现类实现了接口中不需要的抽象方法 //接口 interface Interface1 {void operation1();void operation2();void operation3(); }class B implements Interface1 {public void operation1() {System.out.println(B 实现了 operation1);}public void operation2() {System.out.println(B 实现了 operation2);}public void operation3() {System.out.println(B 实现了 operation3);} } //问题所在A类只用到了B类的 1,2 方法但B类却要实现方法3造成代码的冗余。 class A { //A 类通过接口Interface1 依赖(使用) B类但是只会用到1,2方法public void depend1(Interface1 i) {i.operation1();}public void depend2(Interface1 i) {i.operation2();} }遵循接口隔离原则后将抽象方法进行隔离当需要时实现多个接口即可
// 接口1 interface Interface1 {void operation1();void operation2(); }// 接口2 interface Interface2 {void operation3(); }class B implements Interface1 {public void operation1() {System.out.println(B 实现了 operation1);}public void operation2() {System.out.println(B 实现了 operation2);}}class A { // A 类通过接口Interface1,Interface2 依赖(使用) B类但是只会用到1,2,3方法public void depend1(Interface1 i) {i.operation1();}public void depend2(Interface2 i) {i.operation2();} }三、依赖倒置原则 依赖倒转原则Dependency Inversion PrincipleDIP的定义 程序要依赖于抽象接口不要依赖于具体实现。简单的说就是要求对抽象进行编程不要对实现进行编程这样就降低了客户与实现模块间的耦合。 依赖倒置的原则 1、高层模块不应该依赖底层模块二者都应该依赖其抽象。 2、抽象不应该依赖细节实现类细节应该依赖抽象。 3、依赖倒置的中心思想是面向接口编程。 4、依赖倒置的的设计理念是相对于细节的多样性抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳的多。在 Java 中抽象指的是接口和抽象类细节就是具体的实现类。 5、使用接口或抽象类的目的是定制好规范而不涉及任何具体的操作把展现细节的任务交给他们的实现类去完成。 依赖倒置解决的问题如下方法中传入的参数为类而不是接口 //完成 Person 接收消息的功能:这里receive方法中直接传入的对象是 类 也是依赖倒置重要强调的问题所在。 /1. 如果我们获取的对象是 微信短信等等则新增类同时Perons也要增加相应的接收方法getInfo()* 2. 解决思路引入一个抽象的接口IReceiver, 表示接收者, 这样Person类与接口IReceiver发生依赖* 因为Email, WeiXin 等等属于接收的范围他们各自实现IReceiver 接口就ok, 这样我们就符号依赖倒转原则*/ class Person {public void receive(Email email ) {System.out.println(email.getInfo());} }class Email {public String getInfo() {return 电子邮件信息: hello,world;} }遵循依赖倒置原则后方法中传入的参数修改为接口
public class DependecyInversion {public static void main(String[] args) {Person person new Person();//当为电子邮件时传入邮件对象person.receive(new Email());//当为微信时传入微信对象person.receive(new WeiXin());}}//定义接口 interface IReceiver {public String getInfo(); } //原电子邮件类实现接口 class Email implements IReceiver {public String getInfo() {return 电子邮件信息: hello,world;} }//增加微信 class WeiXin implements IReceiver {public String getInfo() {return 微信信息: hello,ok;} }//方法中传入接口 class Person {//这里我们是对接口的依赖public void receive(IReceiver receiver ) {System.out.println(receiver.getInfo());} }依赖传递的三种方式和案例 【1】接口传递 就是上面举例的方式。 【2】构造方法传递 //方式2: 通过构造方法依赖传递//接口1interface IOpenAndClose {public void open(); //抽象方法}//接口2interface ITV {public void play();}//接口1的方法实现调用接口2接口2的实现通过构造器传入class OpenAndClose implements IOpenAndClose{//成员public ITV tv;//构造器public OpenAndClose(ITV tv){//将传入的对象值复制给自己的成员变量this.tv tv;}//调用的方法public void open(){this.tv.play();}}//————–测试类——————-public class DependencyPass {public static void main(String[] args) {openAndClose.open(changHong);//通过构造器进行依赖传递OpenAndClose openAndClose new OpenAndClose(changHong);openAndClose.open();}}【3】setter 方法传递 将实现类通过 set 方法传入到目标对象中 // 方式3 , 通过setter方法传递 interface IOpenAndClose {public void open(); // 抽象方法//相当于多添加了一个方法只用来获取实现 ITV 接口的实现类并赋值给自己的属性对象。public void setTv(ITV tv); } // ITV接口 interface ITV {public void play(); } //目标类逻辑处理类当tv属性多次使用到时可以用此方法实现 class OpenAndClose implements IOpenAndClose {private ITV tv;public void setTv(ITV tv) {this.tv tv;}public void open() {this.tv.play();} } //接口 ITV 的实现类 class ChangHong implements ITV {Overridepublic void play() {System.out.println(长虹电视机打开);}} //——————–测试—————– public class DependencyPass {public static void main(String[] args) {OpenAndClose openAndClose new OpenAndClose();//通过setter方法进行依赖传递openAndClose.setTv(changHong);openAndClose.open();} }依赖倒置原则的注意事项和细节 1、低层模块尽量都要有抽象类或接口或者两者都有程序稳定性更好。 2、变量的声明类型尽量是抽象类或接口这样我们的变量引用和实际对象间就存在一个缓冲区层对于程序扩展和优化。 3、继承时遵循理氏替换原则 四、里氏替换原则 里氏代换原则Liskov Substitution PrincipleLSP的定义 所有引用基类的地方必须能透明地使用其子类的对象子类可以扩展父类的功能但不能改变父类原有的功能。面向对象(Object Oriented,OO)继承性的思考和说明 1、继承包含这样一层含义父类中凡是已经实现好的方法实际上是在设定规范和契约虽然它不强制要求所有子类都必须遵循这种契约但是如果子类对这些已经实现的方法任意修改就会对这个继承体系造成破坏。 2、继承在给程序设计带来方便的同时也带来了弊端。比如使用继承给程序带来侵入性程序可移植性降低增加对对象间的耦合性。如果一个类被其他的类所继承则当此类需要修改时必须考虑到所有的子类并且父类修改后所有涉及到子类的功能都有可能产生故障。 3、问题提出在编程中如何正确的使用继承答案是遵循里氏替换原则 里氏替换原则基本介绍 1、里氏替换原则是在1988年有麻省理工学院的一名姓里的女士提出的。 2、如果对类型为T1的对象o1对有类型为T2的对象o2使得以T1定义的所有程序P中对象o1可以代替成o2程序 P 的行为没有发生变化那么类型T2是类型T1的子类型。换句话说所有引用基类的地方能透明地使用其子类的对象。 3、在使用继承时遵循里氏替换原则在子类中尽量不要重写父类的方法。 4、里氏替换原则告诉我们继承实际上让两个类耦合性增强了在适当的情况下可以通过聚合、组合、依赖来解决问题。 里氏替换解决的问题如下子类重写了父类的方法 // A类 class A {// 返回两个数的差public int func1(int num1, int num2) {return num1 - num2;} }// B类继承了A // 增加了一个新功能完成两个数相加,然后和9求和 class B extends A {//这里重写了A类的方法, 可能是无意识public int func1(int a, int b) {return a b;}public int func2(int a, int b) {return func1(a, b) 9;} }遵循里氏替换原则后提取一个公共的类将A类与B类进行组合
//创建一个更加基础的基类 class Base {//把更加基础的方法和成员写到Base类 }// A类 class A extends Base {// 返回两个数的差public int func1(int num1, int num2) {return num1 - num2;} }// B类继承了A // 增加了一个新功能完成两个数相加,然后和9求和 class B extends Base {//如果B需要使用A类的方法,使用组合关系private A a new A();//这里重写了A类的方法, 可能是无意识public int func1(int a, int b) {return a b;}public int func2(int a, int b) {return func1(a, b) 9;}//我们仍然想使用A的方法public int func3(int a, int b) {return this.a.func1(a, b);} }五、开闭原则 开闭原则Open Closed PrincipleOCP的定义是 一个软件实体如类、模块和函数应该对扩展开放对修改关闭。模块应尽量在不修改原代码的情况下进行扩展。 开闭原则的基本介绍 1、开闭原则是编程中最基础、最重要的设计原则。 2、一个软件实体如类模块和函数应该对扩展开发提供方对修改关闭使用方。用抽象构建框架用实现扩展细节。 3、当软件需要变化时尽量通过扩展软件实体的行为来实现变化而不是修改已有的代码来实现变化。 4、编程中遵循其他原则以及使用设计模式的目的就是遵循开闭原则 开闭原则解决的问题如下在使用方进行了代码修改 //这是一个用于绘图的类 [使用方] class GraphicEditor {//接收Shape对象然后根据type来绘制不同的图形public void drawShape(Shape s) {//问题所在此类属于使用方但当我们需要扩展新的图形时却要修改使用方就不符合OCP原则if (s.m_type 1) {drawRectangle(s);}else if (s.m_type 2) {drawCircle(s);}}//绘制矩形public void drawRectangle(Shape r) {System.out.println( 绘制矩形 );}//绘制圆形public void drawCircle(Shape r) {System.out.println( 绘制圆形 );} }//Shape类基类 class Shape {int m_type; }class Rectangle extends Shape {Rectangle() {super.m_type 1;} } class Circle extends Shape {Circle() {super.m_type 2;} }遵循开闭替换原则将公共方法提取到抽象类在实现类中实现需要调用的方法使用类中直接调用公共方法即可
//这是一个用于绘图的类 [使用方] class GraphicEditor {//接收Shape对象调用draw方法public void drawShape(Shape s) {//直接调用公共方法即可就算增加新的图形也无需修改此处//当多个地方调用时更能体现OCP的重要性这里只是简单举例s.draw();} }//Shape类基类 abstract class Shape {//抽象方法public abstract void draw(); } //[提供方] class Rectangle extends Shape {Overridepublic void draw() {// TODO Auto-generated method stubSystem.out.println( 绘制矩形 );} }class Circle extends Shape {Overridepublic void draw() {// TODO Auto-generated method stubSystem.out.println( 绘制圆形 );} }六、迪米特法则 迪米特法则Law of DemeterLOD有时候也叫做最少知识原则Least Knowledge PrincipleLKP定义是 一个软件实体应尽可能少地与其他实体发生相互作用。迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖因此很容易使得系统的功能模块独立相互之间不存在或很少有依赖关系。迪米特法则则不希望类之间建立直接的关系。如果真的有需要建立联系也希望能通过它的友元类中间类或者跳转类来转达。 迪米特法则的规则 1、Only talk to your immediate friends(只与直接的朋友通讯)每个对象都会与其他对象有耦合关系只要两个对象之间有耦合关系 我们就说这两个对象之间是朋友关系。耦合的方式很多依赖关联组合聚合等。其中我们称出现成员变量方法参数方法返回值中的类为直接的朋友而出现在局部变量中的类不是直接的朋友例如在一个方法中new了一个类那么此类就不属于直接朋友。也就是说陌生的类最好不要以局部变量的形式出现在类的内部。 2、一个对象应该对其他对象保持最少的了解。 3、类与类关系越密切耦合度越大。 4、迪米特法则指一个类对自己依赖的类知道的 越少越好。也就是说对于被依赖的类不管多么复杂都尽量将逻辑封装在类的内部。对外除了提供的public 方法不对外泄露任何信息。 5、 迪米特法则还有个更简单的定义只与直接的朋友通信。 迪米特法则解决的问题如下 方法中出现了局部变量 //通过查看如下代码会发现CollegeEmployee 以局部变量的形式出现在方法 printAllEmployee 中违反了迪米特法则 public class Demeter1 {//该方法完成输出学校总部和学院员工信息(id)void printAllEmployee(CollegeManager sub) {//分析问题//1. 这里的 CollegeEmployee 不是 SchoolManager的直接朋友//2. CollegeEmployee 是以局部变量方式出现在 SchoolManager//3. 违反了 迪米特法则//获取到学院员工ListCollegeEmployee list1 sub.getAllEmployee();System.out.println(————学院员工————);for (CollegeEmployee e : list1) {System.out.println(e.getId());}}遵循迪米特法则后将局部变量部分提取到自己的类中 public class DemeterUpdate {void printAllEmployee(CollegeManager sub) {//分析问题//1. 将输出学院的员工方法封装到CollegeManagersub.printEmployee();} }//管理学院员工的管理类 class CollegeManager {//输出学院员工的信息public void printEmployee() {//获取到学院员工ListCollegeEmployee list1 getAllEmployee();System.out.println(————学院员工————);for (CollegeEmployee e : list1) {System.out.println(e.getId());}}//返回学院的所有员工public ListCollegeEmployee getAllEmployee() {ListCollegeEmployee list new ArrayListCollegeEmployee();for (int i 0; i 10; i) { //这里我们增加了10个员工到 listCollegeEmployee emp new CollegeEmployee();emp.setId(学院员工id i);list.add(emp);}return list;} }迪米特法则注意事项和细节 1、迪米特法则的核心是降低类之间的耦合。 2、但是注意由于每个类之间都减少了不必要的依赖因此迪米特法则只是要求降低类之间对象间耦合关系并不是要求完全没有依赖关系。 七、合成复用原则 合成复用原则的定义是 原则是尽量使用合成/聚合的方法而不是使用继承。 聚合用来表示“拥有”关系或者整体与部分的关系 代表部分的对象有可能会被多个代表整体的对象所共享而且不一定会随着某个代表整体的对象被销毁或破坏而被销毁或破坏部分的生命周期可以超越整体。例如班级和学生当班级删除后学生还能存在学生可以被培训机构引用。 class OpenAndClose implements IOpenAndClose {private ITV tv;//通过set方法将ITV对象聚合到OpenAndClose对象中public void setTv(ITV tv) {this.tv tv;}public void open() {this.tv.play();} }合成用来表示一种强得多的“拥有”关系 在一个合成关系里部分和整体的生命周期是一样的。一个合成的新对象完全拥有对其组成部分的支配权包括它们的创建和湮灭等。使用程序语言的术语来说合成的新对象对组成部分的内存分配、内存释放有绝对的责任。例如一个人由头、四肢和各种器官组成人与这些具有相同的生命周期人死了这些器官也就挂了。房子和房间的关系当房子没了房间也不可能独立存在。 class OpenAndClose implements IOpenAndClose {//将 ITV 对象组合到 OpenAndClose 对象中ITV tv new ITV(); }【总结】设计原则的核心思想 【1】找出应用中可能需要变化之处把它们独立出来不要和那些不需要变化的代码混在一起。 【2】 针对接口编程而不是针对实现编程。 【3】为了交互对象之间的松耦合设计而努力。 简单理解就是 开闭原则是总纲它指导我们要对扩展开放对修改关闭单一职责原则指导我们实现类要职责单一里氏替换原则指导我们不要破坏继承体系依赖倒置原则指导我们要面向接口编程接口隔离原则指导我们在设计接口的时候要精简单一迪米特法则指导我们要降低耦合。 设计模式就是通过这七个原则来指导我们如何做一个好的设计。但是设计模式不是一套“奇技淫巧”它是一套方法论一种高内聚、低耦合的设计思想。我们可以在此基础上自由的发挥甚至设计出自己的一套设计模式。 当然学习设计模式或者是在工程中实践设计模式必须深入到某一个特定的业务场景中去再结合对业务场景的理解和领域模型的建立才能体会到设计模式思想的精髓。如果脱离具体的业务逻辑去学习或者使用设计模式那是极其空洞的。