设计模式的七条原则 适配器模式实现

简介: 设计模式的七条原则 适配器模式实现

正文


设计模式的七条原则


1、开闭原则


开闭原则的核心是对扩展开放,对修改封闭。在程序需要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。

可以通过“抽象约束、封装变化”来实现开闭原则,即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层,而将相同的可变因素封装在相同的具体实现类中。


2、单一职责原则


单一职责原则规定一个类应该有且仅有一个引起它变化的原因,不要存在多于一个导致类变更的原因,否则就应该把类拆分。

单一职责原则是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,再封装到不同的类或模块中。


3、里氏替换原则


里氏替换原则主要阐述了有关继承的一些原则,也就是什么时候应该使用继承,什么时候不应该使用继承,以及其中蕴含的原理。里氏替换原是继承复用的基础,它反映了基类与子类之间的关系,是对开闭原则的补充,是对实现抽象化的具体步骤的规范。

里氏替换原则通俗来讲就是:子类可以扩展父类的功能,但不能改变父类原有的功能。


4、依赖倒转原则


依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性,它是实现开闭原则的重要途径之一,它降低了客户与实现模块之间的耦合。其核心思想是:要面向接口编程,不要面向实现编程。


4、接口隔离原则


接口隔离原则要求我们尽量将臃肿庞大的接口拆分成更小的和更具体的接口,让接口中只包含客户感兴趣的方法。 每个接口中不存在子类用不到却必须实现的方法,如果不然,就要将接口拆分。使用多个隔离的接口,比使用单个接口要好。


5、迪米特法则


迪米特法则的定义是一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂,都应该将逻辑封装在方法的内部,通过public方法提供给外部。这样当被依赖的类变化时,才能最小的影响该类。

迪米特法则的另一个表达方式是:只与直接的朋友通信。类之间只要有耦合关系,就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。


6、合成复用原则


合成复用原则又叫组合/聚合复用原则,它要求在软件复用时,要尽量先使用组合或者聚合等关联关系来实现,其次才考虑使用继承关系来实现。


如果要使用继承关系,则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的,两者都是开闭原则的具体实现规范。


设计模式如何分类


通常根据模式是用来完成什么工作来划分,这种方式可分为创建型模式、结构型模式和行为型模式,根据运用的范围来划分则式可分为类模式和对象模式两种**


设计模式的划分


设计模式的本质是面向对象设计原则的实际运用,是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解

创建型模式的主要关注点是“怎样创建对象”,它的主要特点是将对象的创建与使用分离。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节,对象的创建由相关的工厂来完成。就像我们去商场购买商品时,不需要知道商品是怎么生产出来一样,因为它们由专门的厂商生产。

结构型模式主要描述如何将类或对象通过组合来实现功能。它主要分为类结构型模式和对象结构型模式,类结构型模式采用继承机制来组织接口和类,对象结构型模式釆用组合或聚合来组合对象。

行为型模式是对在不同的对象之间划分责任和算法的抽象化,用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象无法单独完成的任务,它涉及算法与对象间职责的分配。

类模式:用于处理类与子类之间的关系,这些关系通过继承来建立,是静态的,在编译时刻便确定下来了

对象模式:用于处理对象之间的关系,这些关系可以通过组合或聚合来实现,在运行时刻是可以变化的,更具动态性


范围\目的 创建型模式 结构型模式 行为型模式
类模式 工厂方法 (类)适配器 模板方法、解释器
对象模式 单例 原型 抽象工厂 建造者 代理 (对象)适配器 桥接 装饰 外观 享元 组合 策略 命令 职责链 状态 观察者 中介者 迭代器 访问者 备忘录


创建型模式分为以下5种:


  1. 单例(Singleton)模式:某个类只能生成一个实例,该类提供了一个全局访问点供外部获取该实例,其拓展是有限多例模式。
  2. ** 原型(Prototype)模式**:将一个对象作为原型,通过对其进行复制而克隆出多个和原型类似的新实例。
  3. 工厂方法(FactoryMethod)模式:定义一个用于创建产品的接口,由子类决定生产什么产品。
  4. 抽象工厂(AbstractFactory)模式:提供一个创建产品族的接口,其每个子类可以生产一系列相关的产品。
  5. 建造者(Builder)模式:将一个复杂对象分解成多个相对简单的部分,然后根据不同需要分别创建它们,最后构建成该复杂对象。


结构型模式分为以下 7 种:


  1. 代理(Proxy)模式:为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象,从而限制、增强或修改该对象的一些特性。
  2. 适配器(Adapter)模式:将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
  3. 桥接(Bridge)模式:将抽象与实现分离,使它们可以独立变化。它是用组合关系代替继承关系来实现的,从而降低了抽象和实现这两个可变维度的耦合度。
  4. 装饰(Decorator)模式:动态地给对象增加一些职责,即增加其额外的功能。
  5. 外观(Facade)模式:为多个复杂的子系统提供一个一致的接口,使这些子系统更加容易被访问。
  6. 享元(Flyweight)模式:运用共享技术来有效地支持大量细粒度对象的复用。
  7. 组合(Composite)模式:将对象组合成树状层次结构,使用户对单个对象和组合对象具有一致的访问性。


行为型模式是设计模式中最为庞大的一类,它包含以下 11 种模式:


  1. 模板方法(Template Method)模式:定义一个操作中的算法骨架,将算法的一些步骤延迟到子类中,使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
  2. 策略(Strategy)模式:定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的改变不会影响使用算法的客户。
  3. 命令(Command)模式:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。
  4. 职责链(Chain of Responsibility)模式:把请求从链中的一个对象传到下一个对象,直到请求被响应为止。通过这种方式去除对象之间的耦合。
  5. 状态(State)模式:允许一个对象在其内部状态发生改变时改变其行为能力。
  6. 观察者(Observer)模式:多个对象间存在一对多关系,当一个对象发生改变时,把这种改变通知给其他多个对象,从而影响其他对象的行为。
  7. 中介者(Mediator)模式:定义一个中介对象来简化原有对象之间的交互关系,降低系统中对象间的耦合度,使原有对象之间不必相互了解。
  8. 迭代器(Iterator)模式:提供一种方法来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。
  9. 访问者(Visitor)模式:在不改变集合元素的前提下,为一个集合中的每个元素提供多种访问方式,即每个元素有多个访问者对象访问。
  10. 备忘录(Memento)模式:在不破坏封装性的前提下,获取并保存一个对象的内部状态,以便以后恢复它。
  11. 解释器(Interpreter)模式:提供如何定义语言的文法,以及对语言句子的解释方法,即解释器。


适配器模式


适配器模式是将一个类的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种,前者类之间的耦合度比后者高,且应用相对较少些。


适配器模式的优点:

1、客户端通过适配器可以透明地调用目标接口。

2、复用了现存的类,不需要修改原有代码而重用现有的适配者类。

3、将目标类和适配者类解耦,解决了目标类和适配者类接口不一致的问题。


适配器模式的缺点:

1、适配器编写过程需要结合业务场景全面考虑,可能会增加系统的复杂性。

2、增加代码阅读难度,降低代码可读性,过多使用适配器会使系统代码变得凌乱。

在实际的工作中,有时候会出现公司合并或者收购别的公司的情况(确信),这个时候,就会把其他公司的代码给接收过来,如果遇到相同相似的模块,往往会需要代码合并,适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。或是在使用第三方提供的组件,但组件接口定义和自己要求的接口定义不同,使用适配器模式来解决这个问题。亦或是以前开发的系统存在满足新系统功能需求的类,但其接口同新系统的接口不一致。

以上种种情况,都是我们使用适配器模式的理由。


再提一句:设计模式就是前人经验的结晶,每一种设计模式都解决了特定的问题,使用这些设计模式就是站在了前人的肩膀上。设计模式更多的是让我们学习前人的经验,而不是为了用而用,为了炫技而炫技。


适配器模式的主要角色:

目标接口:当前系统业务所期待的接口,它可以是抽象类或接口。

适配者类:它是被访问和适配的现存组件库中的组件接口。

适配器类:它是一个转换器,通过继承或引用适配者的对象,把适配者接口转换成目标接口,让客户按目标接口的格式访问适配者。


类适配器模式实现


1、目标接口


public interface Smoke {
    //烟草专卖
    public void sellSmoke();
}


2、适配者类


public class GuangdongSmoke implements Smoke{
    //广东省售烟平台在系统内,可以卖烟
    public void companyGD(){
        System.out.println("广东省烟草专卖");
    }
    @Override
    public void sellSmoke() {
        this.companyGD();
    }
}
public class GuiZhouSmoke {
    //贵州省没有接入系统,无法卖烟
    public void companyGZ(){
        System.out.println("贵州省接入烟草专卖");
    }
}


3、适配器类


public class Adapter extends GuiZhouSmoke implements Smoke {
    /**
     *     适配器类,继承了被适配类,实现标准接口
     *     就相当于通过中间代码将贵州的烟草信息接入广州
      */
    @Override
    public void sellSmoke() {
        super.companyGZ();
    }
}


4、测试类


  public static void main(String[] args) {
        //本身功能实现
        Smoke gd =new GuangdongSmoke();
        gd.sellSmoke(); //广东省烟草专卖
        //通过适配器来实现
        Smoke gz =new Adapter();
        gz.sellSmoke();//贵州省接入烟草专卖
    }

上面这种实现的适配器称为类适配器,因为 Adapter 类既继承了 GuiZhouSmoke (被适配类),也实现了 Smoke 接口,在测试类中我们可以根据需要选择并创建任一种符合需求的子类,来实现具体功能。

当然,实际开发中可以参考SpringMvc的适配器。

Spring定义了一个适配接口,使得每一种Controller有一种对应的适配器实现类, 让适配器代替controller执行相应的方法。这样在扩展Controller 时,只需要增加一个适配器类就完成了SpringMVC的扩展了


对象适配器模式实现


另外一种适配器模式是对象适配器,它不是使用继承再实现的方式,而是使用直接关联,或者称为委托的方式。


1、目标接口


public interface Smoke {
    //烟草专卖
    public void sellSmoke();
}


2、适配者类


public class GuangdongSmoke implements Smoke{
    //广东省售烟平台在系统内,可以卖烟
    public void companyGD(){
        System.out.println("广东省烟草专卖");
    }
    @Override
    public void sellSmoke() {
        this.companyGD();
    }
}
public class GuiZhouSmoke {
    //贵州省没有接入系统,无法卖烟
    public void companyGZ(){
        System.out.println("贵州省接入烟草专卖");
    }
}


3、适配器类


这一次适配器类直接关联被适配类,同时实现标准接口


public class Adapter  implements Smoke {
    private GuiZhouSmoke guiZhouSmoke;
    public Adapter(GuiZhouSmoke guiZhouSmoke) {
        this.guiZhouSmoke = guiZhouSmoke;
    }
    /**
     *     适配器类,继承了被适配类,实现标准接口
     *     就相当于通过中间代码将贵州的烟草信息接入广州
      */
    @Override
    public void sellSmoke() {
       this.guiZhouSmoke.companyGZ();
    }
}


4、测试类


  public static void main(String[] args) {
        //本身功能实现
        Smoke gd =new GuangdongSmoke();
        gd.sellSmoke(); //广东省烟草专卖
        //通过适配器来实现
        GuiZhouSmoke guiZhouSmoke =new GuiZhouSmoke();
        Smoke gz =new Adapter(guiZhouSmoke);
        gz.sellSmoke();//贵州省接入烟草专卖
    }    


从IEDA的diagrams图也能看出来,只要Adapter自身拥有一个被适配类的对象,再把具体的特殊功能委托给这个对象来实现。使用对象适配器模式,可以使得 Adapter 类(适配类)根据传入的 Adaptee 对象达到适配多个不同被适配类的功能,当然,此时我们可以为多个被适配类提取出一个接口或抽象类。这样看起来的话,对象适配器模式更加灵活一点。


在 Spring 的 AOP 里通过使用的 Advice(通知)来增强被代理类的功能。Spring 实现这一 AOP 功能的原理就使用代理模式(1、JDK 动态代理。2、CGLib 字节码生成技术代理。)对类进行方法级别的切面增强,即,生成被代理类的代理类,并在代理类的方法前,设置拦截器,通过执行拦截器中的内容增强了代理方法的功能,实现的面向切面编程。


Advice(通知)的类型有:BeforeAdvice、AfterReturningAdvice、ThrowSadvice 等。每个类型 Advice(通知)都有对应的拦截器,MethodBeforeAdviceInterceptor、AfterReturningAdviceInterceptor、ThrowsAdviceInterceptor。Spring 需要将每个 Advice(通知)都封装成对应的拦截器类型,返回给容器,所以需要使用适配器模式对 Advice 进行转换。


适配器模式的应用


适配器模式主要应用于希望复用一些现存的类,但是接口又与复用环境要求不一致的情况。比如在需要对早期代码复用一些功能等应用上很有实际价值。适用场景大致包含三类:

1、已经存在的类的接口不符合我们的需求。

2、创建一个可以复用的类,使得该类可以与其他不相关的类或不可预见的类(即那些接口可能不一定兼容的类)协同作。

3、在不对每一个都进行子类化以匹配它们的接口的情况下,使用一些已经存在的子类。

适配器模式是对现存系统的封装,为现存系统提供一个更为方便的访问接口。适配器模式为事后设计,没有引入新的接口,只是将一个接口通过适配来间接转换为另一个接口。

相关文章
|
3月前
|
设计模式
设计模式七大原则
这篇文章介绍了设计模式中的七大原则,特别强调了单一职责原则,即一个类应该只有一个引起其行为变化的原因,以确保类功能的高内聚和低耦合。
|
3月前
|
设计模式 存储 前端开发
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
React开发设计模式及原则概念问题之自定义Hooks的作用是什么,自定义Hooks设计时要遵循什么原则呢
|
2月前
|
设计模式 Java 关系型数据库
设计模式——设计模式简介和七大原则
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
设计模式——设计模式简介和七大原则
|
5月前
|
设计模式 供应链
设计模式六大原则之迪米特法则
设计模式六大原则之迪米特法则
|
2月前
|
设计模式 Java 程序员
Java设计模式-适配器模式(8)
Java设计模式-适配器模式(8)
|
1月前
|
设计模式 Java
Java设计模式之适配器模式
这篇文章详细讲解了Java设计模式中的适配器模式,包括其应用场景、实现方式及代码示例。
44 0
|
2月前
|
设计模式 Java
设计模式--适配器模式 Adapter Pattern
这篇文章介绍了适配器模式,包括其基本介绍、工作原理以及类适配器模式、对象适配器模式和接口适配器模式三种实现方式。
|
3月前
|
设计模式 XML 存储
【六】设计模式~~~结构型模式~~~适配器模式(Java)
文章详细介绍了适配器模式(Adapter Pattern),这是一种结构型设计模式,用于将一个类的接口转换成客户期望的另一个接口,使原本不兼容的接口能够一起工作,提高了类的复用性和系统的灵活性。通过对象适配器和类适配器两种实现方式,展示了适配器模式的代码应用,并讨论了其优点、缺点以及适用场景。
|
3月前
|
设计模式 算法 开发者
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
设计模式问题之最小知识原则(迪米特法则)对代码设计有何影响,如何解决
|
3月前
|
设计模式 前端开发 JavaScript
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些
React开发设计模式及原则概念问题之什么是HOC(Higher-order component),HOC遵循的设计原则都有哪些