说这个话题之前先讲一个比较高端的思想--'依赖倒置原则'
"依赖倒置是一种软件设计思想，在传统软件中，上层代码依赖于下层代码，当下层代码有所改动时，上层代码也要相应进行改动，因此维护成本较高。而依赖倒置原则的思想是，上层不应该依赖下层，应依赖接口。意为上层代码定义接口，下层代码实现该接口，从而使得下层依赖于上层接口，降低耦合度，提高系统弹性"
上面的解释有点虚，下面我们以实际代码来解释这个理论
比如有这么条需求，用户注册完成后要发送一封邮件，然后你有如下代码：
先有邮件类'Email.class.php'
classMail{
publicfunction send()
{
/*这里是如何发送邮件的代码*/ }
}
然后又注册的类'Register.class.php'
class Register{
private$_emailObj;
publicfunction doRegister()
{
/*这里是如何注册*/$this->_emailObj =newMail();
$this->_emailObj->send();//发送邮件 }
}
然后开始注册
include'Mail.class.php';
include'Register.class.php';
$reg=new Register();
$reg->doRegister();
看起来事情很简单，你很快把这个功能上线了，看起来相安无事... xxx天过后，产品人员说发送邮件的不好，要使用发送短信的，然后你说这简单我把'Mail'类改下...
又过了几天，产品人员说发送短信费用太高，还是改用邮件的好... 此时心中一万个草泥马奔腾而过...
这种事情，常常在产品狗身上发生，无可奈何花落去...
以上场景的问题在于，你每次不得不对'Mail'类进行修改，代码复用性很低，高层过度依赖于底层。接下来，我们就考虑'依赖倒置原则'，让底层继承高层制定的接口，高层依赖于接口。
<?php
interface Mail
{
public function send();
}
class Email implements Mail{
public function send()
{
//发送Email
echo 'i can sent mail<br>';
}
}
class SmsMail implements Mail
{
public function send()
{
//发送短信
echo 'i can send info<br>';
}
}
class Register
{
public $obj;
public function __construct($mailObj)
{
$this->obj = $mailObj;
}
public function doRegister()
{
$this->obj->send();//发送信息
}
}
/* 此处省略若干行 */
$emailObj = new Email();
$smsObj = new SmsMail();
$reg = new Register($emailObj);
$reg->doRegister();//使用email发送
$reg1 = new Register($smsObj);
$reg1->doRegister();//使用短信发送
/* 你甚至可以发完邮件再发短信 */
?>
网友评论