设计模式之开闭原则

设计模式之开闭原则_第1张图片

什么是开闭原则?

开放封闭原则称为OCP原则(Open Closed Principle)是所有面向对象原则的核心。

“开闭原则”是面向对象编程中最基础和最重要的设计原则之一。

软件设计本身所追求的目标就是封装变化、降低耦合,而开放封闭原则正是对这一目标的最直接体现。其他的设计原则,很多时候是为实现这一目标服务的。

为什么要用开闭原则?

如果在进行功能扩展的时候,添加额外的类是没问题的,但因为功能扩展而修改之前运行正常的程序,这是忌讳的,不被允许的。因为一旦修改之前运行正常的程序,就会导致项目整体要进行全方位的重新测试。这是相当麻烦的过程。导致问题的主要原因是:代码和代码之间的耦合度太高。

设计模式之开闭原则_第2张图片

先来看开闭原则的定义:

Software entities like classes,modules and functions should be open for extension but closed for modifications 一个软件实体, 如类, 模块, 函数等应该对扩展开放, 对修改封闭.

这也是开放封闭原则的核心思想:对扩展开放,对修改封闭.

这是什么含义呢?

  • 对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况,也就是指我们系统中的模块、类、方法对它们的提供者(开发者)应该是开放的,提供者可以对系统进行扩展(新增)新的功能。
  • 对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对已有代码进行任何修改,也就是指系统中的模块、类、方法对它们的使用者(调用者)应该是关闭的。使用者使用这些功能时,不会因为提供方新增了功能而导致使用者(调用者)也进行相应修改。

如何实现开放封闭原则呢?

“需求总是变化”、“世界上没有一个软件是不变的”。这里投射出的意思是:需求总是变化的, 可是对于软件设计者来说, 如何才能做到不对原有系统修改的前提下, 实现灵活的扩展. 这就是开闭原则要实现的.

我们在设计系统的时候, 不可能设想一次性把需求确定后, 后面就不改变了.这不科学也不现实的. 既然需求是一定会变化的, 那么我们要如何优雅的面对这种变化呢? 如何设计可以使软件相对容易修改, 不至于需求一变, 就要把整个程序推到重来?

依赖与抽象

实现开放封闭的核心思想就是面对抽象编程,而不是面对具体编程,因为抽象相对稳定。 让类依赖于固定的抽象,所以对修改是封闭的;而通过面向对象的继承和多态机制,可以实现对抽象体的继承,通过覆写其方法来改变固有行为,实现新的扩展方法,所以对于扩展就是开放的。这是实施开放封闭原则的基本思路。

如何落地开闭原则

如果当前的设计不符合开放封闭原则,则必须进行重构。常用的设计模式主要有模板方法(Template Method)设计模式策略(Strategy)设计模式。而封装变化,是实现这一原则的重要手段,将经常发生变化的部分封装为一个类。

开闭原则的重要性

开闭原则是最基础的一个原则,其他五个原则都是它的具体形态。开闭原则是其精神领袖,其他五个原则是指导设计的工具和方法。

  1. 开闭原则对测试的影响

  单元测试通过一个方法一般需要三种方法:正常数据测试,边界数据测试,异常抛出测试,特别重要的可能需要十几个测试方法。如果修改一个实现方法,可能就要修改多个测试方法,这也可能会出现纰漏。所以需要通过扩展来实现业务需求变化。

  2. 开闭原则可以提高复用性

  在面向对象的设计中,所有的逻辑都是从原子逻辑组合而来的,而不是在一个类中独立实现一个业务逻辑。如何提高复用性?缩小逻辑力度,知道一个逻辑不可在拆分为止。

  3. 开闭原则可以提高可维护性

  一款软件投产后,维护人员的工作不仅仅是对数据进行维护,还可能要对程序进行扩展,维护人员最乐意的是就是对一个类进行扩展,而不是修改一个类。

  4. 面向对象开发的要求

   万物皆对象,我们需要把所有的事物都抽象成对象,然后针对对象进行操作,但是万物皆运动,有运动就有变化,有变化就要有策略去应对变化。怎样快速应对呢?这就需要在设计之初考虑到所有可能变化的因素,然后留下接口,等待“可能”转变为“现实"。

如何使用开闭原则

  1、抽象约束

  抽象对一组事物的通用描述,没有具体的实现,也就表示它可以有非常多的可能性,可以跟随需求的变化而变化。因此,通过接口或抽象类可以约束一组可能变化的行为,并且能够实现对扩展开放。 

  2、元数据控件模块行为    

  3、制定项目章程

  4、封装变化

  将相同的变化封装到一个接口或抽象类中,将不同的变化封装到不同的接口或抽象类中,不应该有两个不同变化出现在同一个接口或抽象类中。

注意事项

  开闭原则对扩展开放,对修改关闭,并不意味这不做任何修改,低层模块的的变更,必然要有高层模块进行耦合,否则就是一个孤立无意义的代码片段。

  变化可以归纳为3种:

  1. 逻辑变化

  只变化一个逻辑,而不改变其他模块。可以修改原有类中的方式来完成,前提条件是所有依赖或关联类都按照相同的逻辑处理。

  2. 子模块变化

  一个模块变化,必然会对其他的模块产生影响,特别是一个低层次的模块变化必然引起高层次模块的变化。因此,在通过扩展完成变化是,高层次的模块修改是必然的。

  3.  可见视图变化

  可见视图是提供给客户使用的界面,如JSP程序,Swing界面等,该部分的变化一般会引起连锁反应。最司空见惯的就是业务耦合变化。比如,按原有需求需要展示6列,然后突然有一天需要增加1列,而且这一列需要跨N张表,处理M个逻辑才能展现出来,这样的变化是比较恐怖的,但还是可以通过扩展来完成变化,这就需要看我们原有的设计是否灵活了。

案例1:Windows 的桌面主题设计。

  分析:Windows 的主题是桌面背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的桌面主题,也可以从网上下载新的主题。这些主题有共同的特点,可以为其定义一个抽象类(Abstract Subject),而每个具体的主题(Specific Subject)是其子类。用户窗体可以根据需要选择或者增加新的主题,而不需要修改原代码,所以它是满足开闭原则的,其类图如图 所示。

设计模式之开闭原则_第3张图片

案例2:比如现在国庆节,搞图书打折活动,有以下几种做法:

1.新增打折接口

2.修改原油NewBook类

3.新增打折书籍类

按照开放扩展关闭修改原则,应该是第三种方案,这样原有代码不会受到修改。

//书籍接口
public interface IBook {
    String getBookName();
    String getAuthor();
    int getPrice();
}
//书籍类
public class NewBook implements IBook {
    private String bookName;
    private String author;
    private int price; 
    public NewBook(String bookName, String author, int price){
        this.bookName = bookName;
        this.author = author;
        this.price = price;
    }
    @Override
    public String getBookName() {
        return this.bookName;
    }
    @Override
    public String getAuthor() {
        return this.author;
    }
    @Override
    public int getPrice() {
        return this.price;
    }
}
//打折书籍类
public class OffBook extends NewBook {
    public OffBook(String bookName, String author, int price) {
        super(bookName, author, price);
    }
    public Double getPrice2(){
        return this.getPrice()*0.7;
    }
}

你可能感兴趣的:(设计模式,设计模式,开闭原则,java)