设计模式简介

最新推荐文章于 2022-07-23 00:44:56 发布

一code当先

最新推荐文章于 2022-07-23 00:44:56 发布

阅读量618

点赞数

分类专栏： java中的设计模式文章标签：设计模式 Java设计模式

本文链接：https://blog.csdn.net/xp_xpxp/article/details/97837879

版权

java中的设计模式专栏收录该内容

3 篇文章 0 订阅

订阅专栏

1.什么是设计模式

设计模式（design pattern）是指在软件开发过程中,经过验证的,用于解决在特定环境下,重复出现的,特定问题的解决方案

2.为什么要使用设计模式

编写软件过程中,程序员面临着来自耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性等多方面的挑战,设计模式是为了让程序(软件)具有以下特点:

①.代码重用性 (即:相同功能的代码,不用多次编写)
②.可读性 (即:编程规范性,便于其他程序员的阅读和理解)
③.可扩展性 (即:当需要增加新的功能时,非常的方便,称为可维护)
④.可靠性 (即:当我们增加新的功能后,对原来的功能没有影响)
⑤.使程序呈现高内聚,低耦合的特性(即: 模块与模块之间会有一定的联系,但是不会有很强的代码植入/嵌套)

3.设计模式的七大原则

3.1.单一职责原则

3.1.1.基本介绍

对类来说的,即一个类应该只负责一项职责(注意:并不是说一个类中只能有一个方法,而是有一类(/多个)相似的方法,也可以这样理解,是针对一个对象的多个(操作)方法).如类A负责两个不同职责:职责1,职责2.当职责1需求变更而改变类A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1,A2

3.1.2.应用实例

1>.需求:

以交通工具为例

2>.代码实现:

/**
 * 单一职责原则
 */
public class SingleResponsibilityDemo {

    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.runOnRoad("公交车");
        vehicle.runOnAir("飞机");
        vehicle.runOnWater("轮船");
    }
}

/**
 * ①.虽然没有在类级别上遵守单一职责原则,但在方法上仍然遵守着单一职责原则
 * 类中的方法之后少数几个,可以在方法级别上保持单一职责原则
 */
class Vehicle {
 
    public void runOnRoad(String vehicle) {
        System.out.println(vehicle + "在路上运行...");
    }

    public void runOnAir(String vehicle) {
        System.out.println(vehicle + "在空中运行...");
    }

    public void runOnWater(String vehicle) {
        System.out.println(vehicle + "在水上运行...");
    }
}

3.2.接口隔离原则

3.2.1.基本介绍

客户端不应该去依赖他不需要的接口,即一个类对另一个类的依赖应该建立在最小(少)的接口上

3.2.2.应用实例

1>.需求:

类 A 通过接口 Interface1 依赖类 B,类 C 通过接口 Interface1 依赖类 D,如图:

2>.代码实现:

/**
 * 接口隔离原则
 */
public class SegregationDemo {

    public static void main(String[] args) {
        A a=new A();
        //classA通过接口依赖classB
        a.depend1(new B());
        a.depend2(new B());
        a.depend3(new B());

        //classC通过接口依赖classD
        C c=new C();
        c.depend1(new D());
        c.depend4(new D());
        c.depend5(new D());
    }
}

//将原始的一个接口拆分成多个接口,将接口的方法分散到多个接口中,实现最少依赖
//这个方法是所有类公用的,所以要单独放到一个接口中
interface Interface1{
    public void operation1();
}

//这两个方法是某些类要到的
interface Interface2{
    public void operation2();

    public void operation3();
}

//这两个方法是某些类要到的
interface Interface3{
    public void operation4();

    public void operation5();
}

//classB实现interface1和interface2,使用方法1,2,3
class B implements Interface1,Interface2{

    @Override
    public void operation1() {
        System.out.println("class B 实现了 operation1...");
    }

    @Override
    public void operation2() {
        System.out.println("class B 实现了 operation2...");
    }

    @Override
    public void operation3() {
        System.out.println("class B 实现了 operation3...");
    }
}

//classD实现interface1和interface3,使用方法1,4,5
class D implements Interface1,Interface3{

    @Override
    public void operation1() {
        System.out.println("class D 实现了 operation1...");
    }

    @Override
    public void operation4() {
        System.out.println("class D 实现了 operation4...");
    }

    @Override
    public void operation5() {
        System.out.println("class D 实现了 operation5...");
    }
}

//classA 通过接口interface1,interface2依赖(使用)classB,使用1,2,3三个方法
class A {
    //将 interface1作为参数传入进来
    public void depend1(Interface1 interface1){
        interface1.operation1();
    }

    //将 interface2作为参数传入进来
    public void depend2(Interface2 interface2){
        interface2.operation2();
    }

    //将 interface2作为参数传入进来
    public void depend3(Interface2 interface2){
        interface2.operation3();
    }
}

//classC 通过接口interface1,interface3依赖(使用)classD,使用1,4,5三个方法
class C{
    //将 interface1作为参数传入进来
    public void depend1(Interface1 interface1){
        interface1.operation1();
    }

    //将 interface1作为参数传入进来
    public void depend4(Interface3 interface3){
        interface3.operation4();
    }

    //将 interface1作为参数传入进来
    public void depend5(Interface3 interface3){
        interface3.operation5();
    }
}

3.3.依赖倒转(/倒置)原则

3.3.1.基本介绍

①.依赖倒转(倒置)的中心思想是:面向接口编程

②.高层模块不应该依赖低层模块,二者都应该依赖其抽象(接口/抽象类)

③.抽象不应该依赖细节,细节应该依赖抽象

④.依赖倒转原则是基于这样的设计理念：相对于细节的多变性,抽象的东西要稳定的多;以抽象为基础搭建的架构比以细节为基础的架构要稳定的多.在java中,抽象指的是接口或抽象类,细节就是具体的实现类

⑤.使用接口或抽象类的目的是制定好规范,而不涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成

3.3.2.应用实例

1>.需求:

以接收消息的功能为例

2>.代码实现:

/**
 * 依赖倒转原则
 */
public class DependecyInversion {

    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
        person.receive(new WeiXin());
    }
}

//通过接口接受消息,想要接受什么类型的消息,就传入接口下面具体的实现类即可
//无论要接受何种类型的消息,person客户端类中的代码都不需要修改
class Person {

    public void receive(IReceive iReceive) {
        System.out.println(iReceive.getInfo());
    }
}

//接口
interface IReceive {

    public String getInfo();
}

class Email implements IReceive {

    @Override
    public String getInfo() {
        return "电子邮件信息: Hello World!";
    }
}

class WeiXin implements IReceive {

    @Override
    public String getInfo() {
        return "微信信息: Are You OK?";
    }
}

#扩展:依赖关系传递的三种方式:

①.接口传递(父类的引用可以指向自己的子类对象)

②.构造方法传递

③.setter方法传递

3.4.里氏替换原则

3.4.1.基本介绍

①.里氏替换原则(Liskov Substitution Principle)在1988 年由麻省理工学院的以为姓里的女士提出的,其内容如下:

如果对每个类型为 T1 的对象 o1,都有类型为 T2 的对象 o2,使得以 T1 定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型. 换句话说,所有引用基类的地方必须能透明地使用其子类的对象,即调用父类与子类的同一个方法时,结果要是一样的!

②.使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类中已经实现好的方法

***注意:这里的方法并不是抽象类中的抽象方法,而是已经实现了的普通方法,如果将父类中已经实现了的方法重写的话,就会把原来的业务逻辑覆盖了

3.4.2.应用实例

1>.需求:

对两个数字进行计算

2>.代码实现:

/**
 * 里氏替换原则
 */
public class LiskovDemo {

    public static void main(String[] args) {
        A a = new A();
        System.out.println("10-5=" + (a.func1(10, 5)));  //5

        B b = new B();
        //由于此时类B不再继承类A,所以类B计算两个数之差时不会再认为是func1()方法了
        System.out.println("10-5=" + (b.func3(10, 5)));  //5
        System.out.println("10+5+9=" + (b.func2(10, 5))); //24
    }
}

//创建一个基类
class Base {
    //把更加基础的方法和成员写到base类中
}

//类A,继承了基类Base
class A extends Base {
    public int func1(int num1, int num2) {
        return num1 - num2;
    }
}

//类B,继承了基类Base
class B extends Base {

    //类B使用类A中的方法,此时不直接继承类A,而是将类A作为类B的成员变量建立组合关系
    private A a = new A();

    //无意之中重写了类A中的func1方法,并且将方法的语义改了
    public int func1(int a, int b) {
        return a + b;
    }

    public int func2(int a, int b) {
        return func1(a, b) + 9;
    }

    //类B使用类A中的方法
    public int func3(int num1, int num2) {
        return a.func1(num1, num2);
    }
}

3.5.开闭原则

3.5.1.基本介绍

①.开闭原则是编程中最基础,最重要的设计原则

②.一个软件实体(如类/模块/函数),应该对扩展( 对提供方)开放,对修改(对使用方)关闭.用抽象构建框架,用实现扩展细节

③.当软件需要变化时,尽量通过扩展软件实体的行为(即增加功能)来实现变化,而不是通过修改已有的代码来实现变化

④.编程中遵循其它原则以及使用设计模式的目的就是遵循开闭原则

3.5.2.应用实例

1>.需求:

以一个画图形的功能为例

2>.代码实现:

/**
 * 开闭原则
 * <p>
 * 把图形类shape做成一个抽象类,并且提供一个抽象的draw方法,让子类去实现/扩展
 * 这样每次要创建一个新的图形种类时,只需要让新的图形类继承这个抽象类并且实现draw方法即可
 * 使用方的代码就不需要修改了,满足了开闭原则
 */
public class OcpDemo {
    public static void main(String[] args) {
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawShape(new Triangle2());
        graphicEditor.drawShape(new Circle2());
        graphicEditor.drawShape(new Rectangle2());
        graphicEditor.drawShape(new OtherGraphic());
    }
}

//绘制图形的类型(使用方)
class GraphicEditor {
   
    //这里接受一个抽象类,调用draw抽象方法
    //实际调用过程中接受具体的类,调用每个类自己实现的draw方法
    public void drawShape(Shape shape) {
        shape.draw();
    }
}

//抽象类
abstract class Shape {

    int m_type;

    public abstract void draw();
}

class Rectangle extends Shape {

    Rectangle() {
        super.m_type = 1;
    }

    @Override
    public void draw() {
        System.out.println("绘制矩形...");
    }
}

class Circle extends Shape {

    Circle() {
        super.m_type = 2;
    }

    @Override
    public void draw() {
        System.out.println("绘制圆形...");
    }
}

class Triangle extends Shape {

    Triangle() {
        super.m_type = 3;
    }

    @Override
    public void draw() {
        System.out.println("绘制三角形...");
    }
}

//新增一个图形
class OtherGraphic extends Shape {

    OtherGraphic() {
        super.m_type = 4;
    }

    @Override
    public void draw() {
        System.out.println("绘制其他图形...");
    }
}

3.6.迪米特法则

3.6.1.基本介绍

①.一个对象应该对其他对象保持最少的了解,类与类的关系越密切,耦合度就越大

②.迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的其他类知道的越少越好.也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在(被依赖)类的内部.对外除了提供的 public方法,不对外泄露任何信息

③.迪米特法则的核心是降低类之间的耦合度

3.6.2.应用实例

1>.需求:

有一个学校,下属有各个学院和总部,现要求打印出学校总部员工 ID 和学院员工的 id

2>.代码实现:

/**
 * 迪米特法则
 */
public class DemeterDemo1 {

    public static void main(String[] args) {
        SchoolManager schoolManager = new SchoolManager();
        schoolManager.printAllEmployees(new CollegeManager());
    }
}

//学校总部员工
class Employee {
    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

//学院员工
class CollegeEmployee {

    private String id;

    public String getId() {
        return id;
    }

    public void setId(String id) {
        this.id = id;
    }
}

//管理学院员工的管理类
class CollegeManager {
    public List<CollegeEmployee> getAllEmployee() {
        List<CollegeEmployee> list = new ArrayList<CollegeEmployee>();

        for (int i = 0; i < 10; i++) {
            CollegeEmployee collegeEmployee = new CollegeEmployee();
            collegeEmployee.setId("学院员工,ID=" + i);

            list.add(collegeEmployee);
        }

        return list;
    }

    //使用迪米特法则将方法的实现细节封装在被依赖的对象的内部,然后对外提供一个public方法
    //输出学院员工信息
    public void printCollegeEmployee(){
        List<CollegeEmployee> collegeEmployees = this.getAllEmployee();
        System.out.println("(使用迪米特法则改进的代码)学院员工:");
        for (CollegeEmployee collegeEmployee : collegeEmployees) {
            System.out.println(collegeEmployee.getId());
        }
    }
}

//学校总部员工管理类
class SchoolManager {

    public List<Employee> getAllEmployee() {
        List<Employee> list = new ArrayList<Employee>();

        for (int i = 0; i < 10; i++) {
            Employee employee = new Employee();
            employee.setId("学校员工,ID=" + i);

            list.add(employee);
        }

        return list;
    }

    //打印学校和学院员工信息
    public void printAllEmployees(CollegeManager collegeManager) {

        //调用依赖对外提供的public方法,而不关心方法的实现细节
        collegeManager.printCollegeEmployee();

        List<Employee> employees = this.getAllEmployee();
        System.out.println("学校员工:");
        for (Employee employee : employees) {
            System.out.println(employee.getId());
        }
    }
}

3.7.合成复用原则

3.7.1.基本介绍

如果可以使用合成/聚合的方式来解决类(/对象)之间的依赖关系(/耦合性),那么就尽量不要使用继承

3.7.2.应用实例

1>.需求:

让类B去使用类A中的方法

如图:

2>.代码实现

//类B使用类A中的方法:将类A作为类别的成员变量或者将类A作为类B中某个方法的参数,然后使用类A的方法即可
//代码太简单了,这里就不写了...

3.8.设计原则总结

找出应用中可能需要变化之处,把它们独立出来(封装成接口/抽象类),不要和那些不需要变化的代码混在一起
针对接口编程,而不是针对实现类/细节编程
为了交互对象之间的松耦合(尽量减少类/对象之间的耦合度)设计而努力

一code当先

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫

专栏目录

设计模式简介

文章目录

1.什么是设计模式

2.为什么要使用设计模式

3.设计模式的七大原则

3.1.单一职责原则

3.1.1.基本介绍

3.1.2.应用实例

3.2.接口隔离原则

3.2.1.基本介绍

3.2.2.应用实例

3.3.依赖倒转(/倒置)原则

3.3.1.基本介绍

3.3.2.应用实例

3.4.里氏替换原则

3.4.1.基本介绍

3.4.2.应用实例

3.5.开闭原则

3.5.1.基本介绍

3.5.2.应用实例

3.6.迪米特法则

3.6.1.基本介绍

3.6.2.应用实例

3.7.合成复用原则

3.7.1.基本介绍

3.7.2.应用实例

3.8.设计原则总结