常用设计模式

面向对象的六大设计原则:

  • 单一职责原则

简单来说就是一个类是一组相关性很高的函数、数据的封装。(比如说加载图片,图片的加载逻辑imageLoader和图片的缓存逻辑imageCache应该分开写,加载逻辑不需要知道缓存逻辑,只要缓存结果)。

  • 开闭原则

软件中的对象(类、模块、函数等)对扩展是开放的,对修改是关闭的。(比如加载图片,缓存方式有几种。如果增加缓存方式,如何让加载逻辑imageLoader不修改?那我们可以让图片加载逻辑只依赖缓存逻辑的接口,具体的实现让用户去实现)

  • 里氏替换原则

定义:所有引用基类的地方必须能透明地使用其子类的对象。和开闭原则都强调了一个oop的重要特性—--抽象。抽象又依赖于继承这个特性,继承有以下优缺点:

优点:

1.代码重用,减少创建类的成本,每个子类都拥有父类的方法和属性

2.子类和父类基本相似,但又与父类有所区别

3.提高代码的可扩展性

缺点:

1.继承是侵入性的,只要继承就必须拥有父类的所有属性和方法

2.可能造成子类的代码冗余、灵活性下降,因为子类必须拥有父类的属性和方法

总结:建立抽象,通过抽象建立规范,具体的实现在运行时替换掉抽象,保证系统的扩展性、灵活性。开闭原则和里氏原则是生死相依、不离不弃的,通过里氏替换来达到对扩展开放,对修改关闭的效果。

  • 依赖倒置原则

定义:指定一种特定的解耦形式,使得高层模块不依赖于底层模块的实现细节的目的,依赖模块被倒置了。

关键点:

1.高层模块不应该依赖底层模块,两者应该依赖于抽象

2.抽象不应该依赖于细节

3.细节应该依赖抽象

用Java的语言来表示:模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类发生的。

  • 接口隔离原则

定义:客户端不应该依赖于它不需要的接口,也就是类间的依赖关系应该建立在最小的接口上。

用最小化接口隔离了实现类的细节,也促使我们将庞大的接口拆分到更多细粒度的接口当中,这使我们的系统具有更低的耦合性、更高的灵活性。

总结:前面几大原则可以用几个关键词表示:抽象、单一职责、最小化。

  • 迪米特原则

定义:最小知识原则,也就是只与直接的朋友通信。

通俗的讲就是:一个类应该对自己需要耦合或调用的类知道得最少,类的内部如何实现与调用者或者依赖者没有关系,调用者只知道它需要的方法即可,其他的可一概不管。类与类的关系越密切,耦合度越大,当一个类改变时,对另一个类的影响就越大。

比如我们租房,我们只需要将房间的面积、位置、租金告诉中介,其他一切不管,中介就将我们要求的房子提供给我们就可以了。

常用设计模式

创建型设计模式:

社会化的分工越来越细,自然在软件设计方面也是如此,因此对象的创建和对象的使用分开也就成为了必然趋势。因为对象的创建会消耗掉系统的很多资源,所以单独对对象的创建进行研究,从而能够高效地创建对象就是创建型模式要探讨的问题。

单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式

  • 应用最广泛的模式——单例

定义:确保某个类只有一个实例,而且自行实例化并向整个系统提供这个实例。

使用场景:确保某个类有且只有一个类的场景,避免产生多个对象消耗过多的资源,或者某种类型的对象只应该有且只有一个。

实现单例有如下几个关键点:

  1. 构造函数不对外开放,一般为private
  2. 通过一个静态方法或者枚举返回单例对象
  3. 确保一个对象只有一个,尤其是在多线程环境下
  4. 确保单例对象在反序列化时不会重新创建对象
  • 自由扩展你的项目——Builder模式

定义:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示

主要作用:在用户不知道对象的建造过程和细节的情况下就可以直接创建复杂的对象。

  1. 用户只需要给出指定复杂对象的类型和内容;
  2. 建造者模式负责按顺序创建复杂对象(把内部的建造过程和细节隐藏起来)

Director:导演类,负责已有模块的顺序,然后通知Builder开始建造

Builder:抽象Build类,规范产品的组建,一般由子类实现

ConcreteBuilder:具体建造者,实现具体Builder类定义的所有方法,并且返回一个组建好的对象

Product:产品类

例如:去电脑城买一台组装的台式主机(需要CPU,主板,内存条)

 

 

结构型设计模式

在解决了对象的创建问题之后,对象的组成以及对象之间的依赖关系就成了开发人员关注的焦点,因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。对象结构的设计很容易体现出设计人员水平的高低

适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

  • 装饰者设计模式

定义:动态的给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活。

 

Component:抽象组件,可以是接口或是抽象类,被装饰的最原始的对象。

ConcreteComponent:组件具体实现类。Component的具体实现类,被装饰的具体对象。

Decorator:抽象装饰者,从外类来扩展Component类的功能,但对与Component来说无须知道Decorator的存在。在它的属性中必然有一个Private变量指向Component抽象组件。

ConcreteDecorator:装饰者的具体实现类

例子:吃饭,睡觉,打豆豆。

  • 统一编程接口——外观模式

定义:要求一个子系统的外部与内部的通信必须通过一个统一的对象进行。此模式提供一个高层的接口,使得子系统更易于使用。

Façade:外观类,知道哪些子系统类负责处理请求,将客户端的请求代理给适当的子系统对象。

Subsystem:子系统类,可以有一个或者多个子系统。实现子系统的功能,处理外观类指派的任务,注意子系统类不含有外观类的引用。

外观类的简单实现
子系统类
/**

*  子系统招式

*/

Public class zhaoshi{

    Public void TaiJiQuan(){

        System.out.print(“使用招式太极拳”);

    }

    Public void QiShangQuan(){

        System.out.print(“使用招式七伤拳”);

    }

    Public void ShengHuo(){

        System.out.print(“使用招式圣火令”);

    }

}

/**

*  子系统内功

*/

Public class NeiGong{

    Public void JiuYang(){

        System.out.print(“使用九阳神功”);

    }

Public void QianKun(){

    System.out.print(“使用乾坤大挪移”);

}

}

/**

*  子系统经脉

*/

Public class JingMai{

    Public void jingmai(){

        System.out.print(“开启经脉”);

    }

}

外观类
/**

*  外观类张无忌

*/

Public class ZhangWuJi{

    Private JingMai jingMai;

    Private ZhaoShi zhaoShi;

    Private NeiGong neiGong;

    Public ZhangWuJi(){

        jingMai = new JingMai();

        zhaoShi = new ZhaoShi();

        neiGong = new NeiGong();

    }

    /**

    *  使用乾坤大挪移

    */

    Public void QianKun(){

        jingMai.jingmai();//开启经脉

        neiGong.QianKun();//使用乾坤大挪移

    }

    /**

    *  使用七伤拳

    */

    Public void QiShang(){

        jingMai.jingmai();//开启经脉

        neiGong.QianKun();//使用乾坤大挪移

        zhaoShi.QiShangQuan();//使用招式七伤拳

    }



}

客户端调用


Public class Client(){

  Public static void main(String[] args){

     ZhangWuJi zhangWuJi=new ZhangWuJi();

     //张无忌使用乾坤大挪移

     ZhangWuJi.Qiankun();

     //张无忌使用七伤拳

     ZhangWuJi.QiShang();

}

}

2.外观模式的使用场景和优缺点

使用场景:

1.构建一个有层次结构的子系统时,使用外观模式定义子系统中每每层的入口点,如果子系统是互相依赖的,则可以让其通过外观接口进行通信,减少子系统之间的依赖关系。

2.子系统往往会因为不断的重构演化而变得越来越复杂,大多数的模式使用时也会产生很多很小的类,这给外部调用它们的用户程序带来了使用上的困难。我们可以使用外观类提供 一个简单的接口,对外隐藏子系统的具体实现并隔离变化。

3.当维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展;但因为它含有重要的功能,所以新的需求必须依赖于它,这时可以使用外观类,为设计粗糙或者复杂的遗留代码提供一个简单的接口,让新系统和外观类交互,而外观类负责与遗留的代码交互。

优点:

1.减少系统的相互依赖关系,所有的依赖都是对外观类的依赖,与子系统无关。

2.对用户隐藏了子系统的具体实现,减少用户对子系统的耦合。这样即使具体的子系统发生了变化,用户也不会感知到。

3.加强了安全性,子系统中的方法如果不在外观类中开通,就无法访问到子系统中的方法。

缺点:不符合开发封闭原则。如果业务出现变更则可能直接修改外观类。

 

行为型设计模式

在对象的结构和对象的创建问题都解决了之后,就剩下对象的行为问题了,如果对象的行为设计的好,那么对象的行为就会更清晰,它们之间的协作效率就会提高

策略模式、模板方法、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

  • 抓问题的核心---模板方法模式

定义:定义一个操作中的算法的框架,而将一些步骤延迟到子类中,使得子类可以不改变一个算法的结构即可重新定义该算法框架的某些特定的步骤。

使用场景:

1.多个子类有公有的方法,并且逻辑基本相同时

2.把核心算法设计为模板方法,周边的细节由各个子类实现

3.把相同的代码抽取到父类,然后通过钩子函数约束其行为

比如:我们冲泡茶的例子

茶冲泡法: 1.把水煮沸、2.用沸水冲泡茶叶、3.把 茶 倒进杯子、4.加蜂蜜

父类:饮料

public abstract class Beverage {

    /**

     * 冲泡咖啡或茶...流程

     */

    public final void create(){

        boilWater();//把水煮沸

        brew();//用沸水冲泡...

        pourInCup();//把...倒进杯子

        addCoundiments();//加...

    }

    public abstract void addCoundiments();

    public abstract void brew();

    public void boilWater() {

        System.out.println("煮开水");

    }

    public void pourInCup() {

        System.out.println("倒进杯子");

    }

}

子类:茶

public class Tea extends Beverage{

    @Override
    public void addCoundiments() {
        System.out.println("添加蜂蜜");
    }

    @Override
    public void brew() {
        System.out.println("用水冲茶");
    }

}
  •  解决解耦的钥匙——观察者模式

定义:定义对象间一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖它的对象都会得到通知并自动更新。

包含四个角色:

  • 抽象被观察者角色:也就是一个抽象主题,它把所有对观察者对象的引用保存在一个集合中,每个主题都可以有任意数量的观察者。抽象主题提供一个接口,可以增加和删除观察者角色。一般用一个抽象类和接口来实现。
  • 抽象观察者角色:为所有的具体观察者定义一个接口,在得到主题通知时更新自己。
  • 具体被观察者角色:也就是一个具体的主题,在集体主题的内部状态改变时,所有登记过的观察者发出通知。
  • 具体观察者角色:实现抽象观察者角色所需要的更新接口,一边使本身的状态与制图的状态相协调。

 

例如: 有一个微信公众号服务,不定时发布一些消息,关注公众号就可以收到推送消息,取消关注就收不到推送消息

  1. 定义一个抽象被观察者接
/***
 * 抽象被观察者接口
 * 声明了添加、删除、通知观察者方法
 * @author chenli
 *
 */
public interface Observerable {
    
    public void registerObserver(Observer o);
    public void removeObserver(Observer o);
    public void notifyObserver();
    
}

定义一个抽象观察者接口
/***
 * 抽象观察者
 * 定义了一个update()方法,当被观察者调用notifyObservers()方法时,观察者的update()方法会被回调。
 * @author chenli
 *
 */
public interface Observer {
    public void update(String message);
}
定义被观察者,实现了Observerable接口,对Observerable接口的三个方法进行了具体实现,同时有一个List集合,用以保存注册的观察者,等需要通知观察者时,遍历该集合即可。
/**

 * 被观察者,也就是微信公众号服务

 * 实现了Observerable接口,对Observerable接口的三个方法进行了具体实现

 * @author chenli

 *

 */

public class WechatServer implements Observerable {

   

    //注意到这个List集合的泛型参数为Observer接口,设计原则:面向接口编程而不是面向实现编程

    private List list;

    private String message;

   

    public WechatServer() {

        list = new ArrayList();

    }

   

    @Override

    public void registerObserver(Observer o) {

        list.add(o);

    }

   

    @Override

    public void removeObserver(Observer o) {

        if(!list.isEmpty())

            list.remove(o);

    }



    //遍历

    @Override

    public void notifyObserver() {

        for(int i = 0; i < list.size(); i++) {

            Observer oserver = list.get(i);

            oserver.update(message);

        }

    }

   

    public void setInfomation(String s) {

        this.message = s;

        System.out.println("微信服务更新消息: " + s);

        //消息更新,通知所有观察者

        notifyObserver();

    }

}



4、定义具体观察者,微信公众号的具体观察者为用户User

/**
 * 观察者
 * 实现了update方法
 * @author chenli
 *
 */
public class User implements Observer {

    private String name;
    private String message;
    
    public User(String name) {
        this.name = name;
    }
    
    @Override
    public void update(String message) {
        this.message = message;
        read();
    }
    
    public void read() {
        System.out.println(name + " 收到推送消息: " + message);
    }
    
}

 

你可能感兴趣的:(android相关)