电子商务公司设计网站建设免费检测网站seo
一、介绍
在软件工程中，设计模式（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_type=1;}
}class Circle extends Shape {Circle(){super.m_type=2;}
}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）为了交互对象之间的松耦合设计而努力