开闭原则

软件设计中的开闭原则

以下来自百度百科，之所以手抄一遍，是帮助自己细致读一遍。之间会加入自己的思考及疑问。

       开闭原则是面向对象设计中“可复用设计”的基石，是面向对象设计中最重要的原则之一，其他很多的设计原则都是实现开闭原则的一种手段。1988年，Bertrand Meyer在他的著作《Object Oriented Software Construction》中提出了开闭原则，它的原文是这样：“Software entities should be open for extension，but closed for modification”。翻译过来就是：“软件实体应当对扩展开放，对修改关闭”。这句话说的略微有点专业，通俗讲，就是：软件系统中包含的各种组件，例如模块（Modules）、类（classes）、以及功能（Functions）等等，应该在不修改现有代码的基础上，引入新功能。开闭原则中的“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中的“闭”，是指对于原有代码的修改是关闭的，即不应该修改原有的代码。

 

开闭原则的实现

     实现开闭原则的关键就在于“抽象”。把系统的所有可能的行为抽象成一个抽象底层，这个抽象底层规定出所有的具体实现必须提供的方法的特征。作为系统设计的抽象层，要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象底层不需要修改；同时，由于可以从抽象底层导出一个或多个新的具体实现，可以改变系统的行为，因此系统设计对扩展是开放的。“我们在软件开发的过程中，一直都是提倡需求导向的。这就要求我们在设计的时候，要非常清楚地了解用户需求，判断需求中包含的可能的变化，从而明确在什么情况下使用开闭原则。”

      关于系统可变的部分，还有一个更具体的可变性封装原则（Principle of Encapsulation of Variation，EVP），它从软件工程实现的角度对开闭原则进行了进一步的解释。EVP要求在做系统设计的时候，对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装。我们在实际开发过程的设计开始阶段，就要罗列出来系统所有可能的行为，并把这些行为加入到底层抽象，根本就是不可能的，这么做也是不经济的，费时费力。另外，在设计开始阶段，对所有的可变因素进行预计和封装也不太现实，也是很难做得到。所以，开闭原则描绘的愿景只是一种理想情况或是极端状态，现实世界中是很难被完全实现的。我们只能在某些组件，在某种程度上符合开闭原则的要求。通过以上的分析，对于开闭原则，我们可以得出这样的结论：虽然我们不可能做到百分百的封闭，但是在系统设计的时候，我们还是要尽量做到这一点。对于软件系统的功能扩展，我们可以通过继承、重载或者委托等手段实现。以接口为例，它对修改就是封闭的，而对具体的实现是开放的，我们可以根据实际的需要提供不同的实现，所以接口是符合开闭原则的。

 

开闭原则的好处

      如果一个软件系统符合开闭原则的，那么从软件工程的角度来看，它至少具有这样的好处：可复用性好。我们可以在软件完成以后，仍然可以对软件进行扩展，加入新的功能，非常灵活。因此，这个软件系统就可以通过不断地增加新的组件，来满足不断变化的需求。

可维护性好

      由于对于已有的软件系统的组件，特别是它的抽象底层不去修改，因此，我们不用担心软件系统中原有组件的稳定性，这就使变化中的软件系统有一定的稳定性和延续性。

 

开闭原则与其他原则的关系

      开闭原则具有理想主义色彩，它是面向对象设计的终极目标。因此，针对开闭原则的实现方法，一直都有面向对象设计的大师费尽心机，研究开闭原则的实现方式。后面要提到的里氏代换原则（LSP）、依赖倒转原则（DIP）、接口隔离原则（ISP）、以及抽象类（Abstract Class）、接口（Interface）等等，都可以看做是开闭原则的实现方法。

 

Thinking

开闭原则比较典型的应用一个是抽象类，一个是接口。

举例接口如下：

定义一个访问数据库的接口DataBaseJDBC.java,其中定义了连接数据库的方法，访问数据库的方法

public interface DataBaseJDBC{

public String Conn()；

 

public String search()；

 

}

 

现在是用Mysql，

具体实现类：

public class DataBaseJDBCMysql implements DataBaseJDBC{

public String Conn(){

.....//具体实现Mysql

}

 

public String search(){

.......//具体实现Mysql

}

 

}

 

调用数据库服务的时候，调用方法为：

DataBaseJDBC DbJDBC=new DataBaseJDBCMysql();

访问为：

DbJDBC.conn();

DbJDBC.search();

 

后来公司要上市，决定烧钱了，于是改用oracle，这时候，对于实现类，显然需要增加访问oralce的类

public class DataBaseJDBCOracle implements DataBaseJDBC{

public String Conn(){

.....//具体实现oracle

}

 

public String search(){

.......//具体实现oracle

}

}

 

这时候，调用数据库的服务只需要改下面一句，将调用Mysql的类改为调用Oracle的类即可。

调用数据库服务的时候，调用方法为：

DataBaseJDBC DbJDBC=new DataBaseJDBCoracle();

在调用服务中，访问服务仍然为：

DbJDBC.conn();

DbJDBC.search();

 

在这里，牵扯出两个问题，一个是不同数据库需要的访问参数可能不同，返回值可能不同，怎么办？

一个是有没有更简单的办法，调用数据库的服务都不需要改，因为一个项目中可能会有很多调用数据库服务的地方，如果调整，都需要调整。

 

对于第二个问题，后续在讲Spring基础时再说。这个是很多框架考虑的一个方面。

 

对于第一个问题，这个就是考验设计者的经验和能力的东西了。这就是在文章中提到的，设计时要根据实际需求考虑扩展性。例如传递参数的问题，可以考虑传递参数的通用性，这又是更细致层面的开闭原则。例如，入参和出参可以用Map来实现，避免实际的参数类型不匹配，在访问数据库的类内部再根据不同的数据库分别解析。

 

现在能想到的开闭原则，有几个应用场景：

1、接口

2、抽象类

3、公共方法，即项目中公共的服务单独出来。例如访问数据库的方法，调用其他系统的方法。

4、业务逻辑与非业务逻辑分开。

5、系统之间调用，采用接口调用。

 

此外，将系统中的公共方法，包括基础公共方法和业务逻辑公共方法都封装为原子方法，也是开闭原则很好的实现。

 

最后，还想考虑就是过度设计的问题以及过度封装导致性能的问题。由于对开闭原则本身理解都不深入，待深入了解后再来考虑这些问题。