设计原则之开放闭合原则（OCP）

qq524061227

　　在《敏捷软件开发-原则、模式与实践》一书中，对开放闭合原则的定义为：
　　软件实体（类、模块、函数等）应该是可以扩展的，但是不可以修改。
　　简言之，两个特征：
　　1、对于扩展是开放的；
　　2、对于修改是关闭的
　　这两点特征貌似自相矛盾，怎么样在不改动模块源码的情况下去更改他的行为呢？如果不更改一个模块，又怎么能够去改变它的功能呢？
　　答案很简单，就是抽象。模块可能对抽象体进行操作。由于模块依赖于一个固定的抽象体，所以他对于更改可以是封闭的。同时，通过从这个抽象体去派生，可以扩展此模块的行为。
　　


　　在设计原则开篇一文中已经举例说明了如何应用这个原则。在这篇文章中再举一个例子，帮助大家加深认识。
　　


　　如果你有去看zend framework的源码，其中有一段代码是用来解析配置文件的，这次就拿这个案例来举例。
　　version1：
　　有多个配置文件：config.php、config.json、config.xml
　　config.php:
　　

<?php
return array(
'database' => array(
'host' => '127.0.0.1',
'username' => 'root',
'password' => '',
'dbname' => 'test'
)
);config.json:

{
&quot;database&quot;:{
&quot;host&quot;:&quot;127.0.0.1&quot;,
&quot;username&quot;:&quot;root&quot;,
&quot;password&quot;:&quot;&quot;,
&quot;dbname&quot;:&quot;test&quot;
}
}config.xml:　　
　　

<?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?>
<config>
<database>
<host>127.0.0.1</host>
<username>root</username>
<password></password>
<dbname>test</dbname>
</database>
</config>

　　我们将配置文件交给config类去处理：
　　

public function configToArray($configFile){
$extension = pathinfo($configFile, PATHINFO_EXTENSION);
$config = array();
switch ($extension) {
case 'php':
$config = require_once $configFile;
break;
case 'xml':
$xml = simplexml_load_file($configFile);
return json_decode(json_encode($xml), true);
case 'json':
$config = json_decode(file_get_contents($configFile), true);
break;
}
foreach ($config as $key => $value) {
$this->set($key, $value);
}
}


　　
　　这样的弊端在于，后期如果希望使用新的配置文件，比如ini文件、yaml文件等，我们就需要到switch语句里面去新增case。
　　现在来看version 2的设计：
　　首先声明了一个接口Configuration：
　　

<?php
interface Configuration{
public function toArray($configFilePath);
}然后新增了3个具体的实现类：　　
　　jsonConfiguration.php


　　

<?php
require_once &quot;configuration.php&quot;;
class JsonConfiguration implements Configuration{
public function toArray($configFilePath){
return json_decode(file_get_contents($configFilePath), true);
}
}phpConfiguration.php　　
　　

<?php
require_once &quot;configuration.php&quot;;
class phpConfiguration implements Configuration{
public function toArray($configFilePath){
$config = require_once $configFilePath;
return $config;
}
}xmlConfiguration.php

<?php
require_once &quot;configuration.php&quot;;
class XmlConfiguration implements Configuration{
public function toArray($configFilePath){
$xml = simplexml_load_file($configFilePath);
return json_decode(json_encode($xml), true);
}
}这样config类中的代码就可以修改为：　　
　　

public function configToArray(Configuration $configuration){
$config = is_array($configuration->toArray($this->configFilePath)) ? $configuration->toArray($this->configFilePath) : array();
foreach ($config as $key => $value) {
$this->set($key, $value);
}
}
　　
　　这样我们想再增加一个配置文件时，就可以新增一个实现类就可以了。也就做到了“对修改关闭，对扩展开放”了。
　　这个案例和设计原则开篇一文中提到的案例非常相&#20284;，可以概括为“如何将if/else转换为抽象”和“如何将switch转换为抽象”，
　　


　　在许多方面，OCP都是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处：灵活性、可重用性和可维护性。然而，并不是说只要使用一种面向对象语言就是遵循了这个原则。对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意。正确的做法是，开发人员应该仅仅对程序中呈现出频繁变化的那些部分做出抽象。拒绝不成熟的抽象和抽象本身一样重要。

版权声明：本文为博主原创文章，转载请注明出处和作者名，尊重别人也是尊重自己