面向对象编程的六大原则
一.单一职责:
不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
我们最开始设计了一个类Human,我们赋予了四项功能.
以下是伪代码:
class Human
{
public function 教书();
public function 讲课();
public function 听课();
public function 写作业();
}
但我们发现,一个人不会既教书,又写作业,也不会既听课,又讲课.
所以我们将其拆分:
class Teacher
{
public function 教书();
public function 讲课();
}
class Student
{
public function 听课();
public function 写作业();
}
这就比较好的符合单一职责.
二.里氏替换原则:
所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类可以扩展父类的功能，但不能改变父类原有的功能
伪代码:
class 基类
{
public function say(){return '基类';}
}
class 子类 extends 基类
{
public function say($msg)
{
return $msg;
}
}
$a = new 基类();
$b = new 子类();
echo $b->say('子类');
子类重写了父类的方法,say要传入参数,导致了导致了父类原有的功能被改变了,这违背了里氏替换原则.
三.依赖倒置:
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。简单的说就是尽量面向接口编程.
我们需要在用户积分增加的时候,写入一个日志文件.最开始我们写入文件中.
class User
{
................
public function addPoint($dValue, Log log)
{
$this->point += $dValue;
$log->writeLog($this);
}
...............
}
class Log
{
public function writeLog(User $user)
{
write_log_to_file....
}
}
// 调用
$user = new User();
$user->addPoint(100, new Log());
后面需求有变化,需要写入数据库
class User
{
................
public function addPoint($dValue, Log log)
{
$this->point += $dValue;
$log->writeLog($this);
}
...............
}
class DbLog
{
public function writeLog(User $user)
{
write_log_to_db....
}
}
// 调用
$user = new User();
$user->addPoint(100, new Log());
代码改动颇大,每次需求的变化都需要改动许多代码,我们现在建立一个接口,所有的日志类都继承该接口.我们让User类中的addPoint依赖该接口.
interface ILog{
public function writeLog(User $user);
}
class Log implements ILog
{
public function writeLog(User $user)
{
write_log_to_file....
}
}
class DbLog implements ILog
{
public function writeLog(User $user)
{
write_log_to_db....
}
}
class User
{
................
public function addPoint($dValue, ILog log)
{
$this->point += $dValue;
$log->writeLog($this);
}
...............
}
// 调用
$user = new User();
$user->addPoint(100, new Log());
$user->addPoint(100, new DbLog());
这样子后面无论再增加其他日志类,只要实现了ILog,均可以调用.
四.接口隔离:
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口最小化,过于臃肿的接口依据功能,可以将其拆分为多个接口.
interface IUser{
注册接口
登录接口
充值接口
充值记录接口
手动充值(用于充值失败时,手动补发)
}
但实际中,我们发现手动充值在User类中用不到,因为这显然是个后台管理用户才可以用到.不符合接口隔离原则.我们拆分该接口.
interface IUser
{
注册接口
登录接口
充值接口
充值记录接口
}
interface IManageUser
{
手动充值(用于充值失败时,手动补发)
}
五.迪米特法则:
一个对象应该对其他对象保持最少的了解,简单的理解就是高内聚,低耦合，一个类尽量减少对其他对象的依赖，并且这个类的方法和属性能用私有的就尽量私有化.
class Product
{
......
public function buy(){...}
public function repertory(){...}
......
}
这是一个产品类,我们期望用户在购买掉一个产品后,该产品的库存减去1.用户购买了,产品库存才会减去1.减库存,依赖于购买.所以我们应该将repertory声明为private,其他对象也只需要了解该对象的buy即可.
class User
{
........
public function log(Log $log)
{
$log->writeLog(.....);
}
........
}
class Log
{
// 写日志
public function writeLog(User $user)
{
$log->writeLog(.....);
}
// 打印日志
public function printLog(User $user)
{
.....
}
}
我们期望对User类的某些操作,记录日志.但User类log方法依赖Log类,但Log类的printLog方法,User类并不需要,这应该要看日志的系统管理员如:AdminUser需要的方法.
去掉Log类的printLog方法
class Log
{
// 写日志
public function writeLog(User $user)
{
$log->writeLog(.....);
}
}
或者面向接口:
interface ILog
{
public function writeLog(User $user);
}
class Log implements ILog
{
// 写日志
public function writeLog(User $user)
{
$log->writeLog(.....);
}
// 打印日志
public function printLog(User $user)
{
.....
}
}
class User
{
........
public function log(ILog $log)
{
$log->writeLog(.....);
}
........
}
六.开闭原则:
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭.当软件需求变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化.
我们有个产品基类,提供了一些列的方法:
class Product
{
............
一系列的方法
............
}
但随着业务的发展,我们需要Product能够提供打折功能.这个时候我们是直接在Product中增加一个discount方法?还是再扩展一个子类?
打折显然不是所有产品都需要的,如果所有产品都需要,我们一开始就会将其设计进去.可能只是BookProduct需要,所以我们应该扩展一个子类.这既没有修改原有的类,又扩展了该类的功能.符合了开闭原则.
class DiscountProduct extends Product
{
............
discount()
............
}
ps:过于严苛的遵守六大原则,将分层变多,类变多,项目变的非常庞大.所以对这些原则要根据实际情况做出取舍.一般分层不要超过6层.超过6层,代码变的难以维护也难以跟踪.
