这里写目录标题
参考:刘伟老师
https://blog.csdn.net/lovelion/article/details/17517213
设计 模式的目的
编写软件过程中,程序员面临着来自耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性 等多方面的挑战,设计模式是为了让程序(软件),具有更好的
1)代码重用性 (即:相同功能的代码,不用多次编写)
2)可读性 (即:编程规范性, 便于其他程序员的阅读和理解)
3)可扩展性 (即:当需要增加新的功能时,非常的方便,称为可维护)
4)可靠性 (即:当我们增加新的功能后,对原来的功能没有影响)
使程序呈现高内聚,低耦合的特性
七大原则
设计模式的六大原则有:
- Single Responsibility Principle:单一职责原则
- Open Closed Principle:开闭原则
- Liskov Substitution Principle:里氏替换原则
- Law of Demeter:迪米特法则
- Interface Segregation Principle:接口隔离原则
- Dependence Inversion Principle:依赖倒置原则
把这六个原则的首字母联合起来(两个 L 算做一个)就是 SOLID (solid,稳定的)
再加一个:
- 合成复用原则
单一职责原则
对类来说的,即一个类应该只负责一项职责。
开闭原则
开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
做法:
为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在Java、C#等编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制,可以通过它们定义系统的抽象层,再通过具体类来进行扩展。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。
xml和properties等格式的配置文件是纯文本文件,可以直接通过VI编辑器或记事本进行编辑,且无须编译,因此在软件开发中,一般不把对配置文件的修改认为是对系统源代码的修改。如果一个系统在扩展时只涉及到修改配置文件,而原有的Java代码或C#代码没有做任何修改,该系统即可认为是一个符合开闭原则的系统。
接口隔离原则
做法:
将接口拆分,一个类实现一个接口改为实现多个具有更具体功能的接口。
好处
-
避免接口污染:
一个类如果要实现一个接口,那么就要实现这个接口要求的所有方法,如果这个接口里面包含这个类不需要的方法,那么就会造成接口污染,这是不好的设计,会对系统留下隐患。 -
提高灵活性
-
提供定制服务
依赖倒转(倒置)原则
https://juejin.im/post/6844904117173747726
原则
1.上层模块不应该依赖底层模块,它们都应该依赖于抽象。
2.抽象不应该依赖于细节,细节应该依赖于抽象。
上下层
上层:业务层,要进行的操作,就是做什么
底层:逻辑层,数据层,实现细节,就是怎么做
举例子:出门
依赖倒置实质上是面向接口编程的体现
控制反转(IoC, Inversion of Control):
其实就是好莱坞原则(don’t call me, I’ll call you);
比如Netty框架调用用户自定义的Handler,Spring MVC根据请求调用Controller。
里氏代换原则
所有引用基类(父类)的地方必须能透明地使用其子类的对象。
里氏代换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类对象来替换父类对象。
合成复用原则
合成复用原则(Composite Reuse Principle, CRP):尽量使用对象组合,而不是继承来达到复用的目的。
迪米特法则
一个软件实体应当尽可能少地与其他实体发生相互作用。
如果一个系统符合迪米特法则,那么当其中某一个模块发生修改时,就会尽量少地影响其他模块,扩展会相对容易,这是对软件实体之间通信的限制,迪米特法则要求限制软件实体之间通信的宽度和深度。迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系。
迪米特法则还有几种定义形式,包括:不要和“陌生人”说话、只与你的直接朋友通信等,在迪米特法则中,对于一个对象,其朋友包括以下几类:
(1) 当前对象本身(this);
(2) 以参数形式传入到当前对象方法中的对象;
(3) 当前对象的成员对象;
(4) 如果当前对象的成员对象是一个集合,那么集合中的元素也都是朋友;
(5) 当前对象所创建的对象。
任何一个对象,如果满足上面的条件之一,就是当前对象的“朋友”,否则就是“陌生人”。在应用迪米特法则时,一个对象只能与直接朋友发生交互,不要与“陌生人”发生直接交互,这样做可以降低系统的耦合度,一个对象的改变不会给太多其他对象带来影响。
建造型设计模式
简单工厂模式
工厂方法模式
抽象工厂模式
- 产品是不同维度的属性的组合,比如红,绿色的裤子,上衣,和鞋子
具体属性:裤子,上衣,和鞋子
抽象属性:红,绿
//鞋子接口:抽象产品
interface Shoes{
public void sale();
}
class RedShoes implements shoes{
public void sale() {
System.out.println("10");
}
}
class GreenShoes implements shoes{
public void sale() {
System.out.println("10");
}
}
//上衣
interface Coat{
public void sale();
}
class redcoat implements coat{
public void sale() {
System.out.println("110");
}
}
class greencoat implements coat{
public void sale() {
System.out.println("10");
}
}
//裤子
interface Pants{
public void sale();
}
class redpants implements pants{
public void sale() {
System.out.println("110");
}
}
class greenpants implements pants{
public void sale() {
System.out.println("10");
}
}
//抽象工厂
interface ClothesFactory{
public Shoes createShoes();
public Coat createCoat();
public Pants createPants();
}
class GreenClothesFactory implements ClothesFactory{
public Shoes createShoes() {
return new GreenShoes ();
}
public Coat createCoat() {
return new GreenCoat();
}
public Pants createPants() {
return new GreenPants();
}
}
class RedClothesFactory implements ClothesFactory{
public Shoes createShoes() {
return new RedShoes();
}
public Coat createCoat() {
return new RedCoat();
}
public Pants createPants() {
return new RedPants ();
}
}
单例模式(Singleton pattern)
用于Runtime,Calendar和其他的一些类中。
工厂模式(Factory pattern)
被用于各种不可变的类如 Boolean,像Boolean.valueOf,
观察者模式(Observer pattern)
被用于 Swing 和很多的事件监听中。
装饰器设计模式(Decorator design pattern)
被用于多个 Java IO 类中。
结构型
适配器模式
对象适配器
简洁明了
class Adapter extends Target {
private Adaptee adaptee; //维持一个对适配者对象的引用
public Adapter(Adaptee adaptee) {
this.adaptee=adaptee;
}
public void request() {
adaptee.specificRequest(); //转发调用
}
}
类适配器
类适配器模式和对象适配器模式最大的区别在于适配器和适配者之间的关系不同,对象适配器模式中适配器和适配者之间是关联关系,而类适配器模式中适配器和适配者是继承关系
class Adapter extends Adaptee implements Target {
public void request() {
specificRequest();
}
}