PHP设计模式的六大设计原则
PHP设计模式的六大设计原则
1 简介
软件设计最大的难题就是应对需求的变化,但是纷繁复杂的需求变化却是不可预料的.此时,我们可以通过六大设计原则良好的应对未来的变化.
2 讲解
2.1 单一职责原则(Single Responsibility Principle)
简单的例子,用户发送一个请求到服务器,当我们所有的操作只用一个action类来完成
那么当需求业务比如安全检查逻辑有变动时,我们都将修改这个类,繁琐而没有条理,极不容易维护.
若我们把路由-安全-缓存等都封装成类,就仅在getResp()调用即可,简单优雅.
2.2 开闭原则(Open Closed Principle)
小孩每天要做家庭作业
突然有一天老实宣布,临近期中考试了,作业要做两次.考完恢复成做一次.倘若我们直接修改Homework类的finHomework函数,虽然可以解决问题,但是期中考试结束后又需要把函数改回来.最好的解决办法就是利用开闭原则:
2.3 里氏替换原则(Liskov Substitution Principle)
我们设计了Mp4类,它具有听歌和看视频的功能.
有一天我们要构建mp3的类,继续依照mp4的接口来生成类的话,会发现播放视频的功能用不了.
此时我们可以构造IMp3接口来适应此种情况,我们还可以拓展处lookMini功能函数,符合里氏替换原则.
2.4 迪米特法则(Law of Demeter)
系统判定英雄是否赢取lol游戏,需要观察英雄完成三步:清理兵线-推塔-胜利.
以上的Hero类中暴露了太多方法给system类,两者的耦合关系异常牢固.以下设计方法可以解决此问题.
2.5 接口隔离原则(INterface Segregation Principle)
有两个手机用户,用户1拿手机听歌,用户2拿手机打游戏接电话,场景实现如下:
我们发现,接口 IPhone 中出现的方法,不管依赖于它的类有没有作用,实现类的时候都要实现这些方法.若我们依据接口隔离原则,便可以解决以上问题.
2.6 依赖倒置原则(Dependence Inversion Principle)
以下是用户吃晚餐的场景:
但是如果我们不止吃米饭,还喝汤呢,发现Rice
并不适用了。我们引入一个抽象的接口Ifood
,代表读物。让Mother类与接口Ifood
发生依赖关系,而Rice
和Soup
都属于食物的范畴,让他们各自都去实现IReader接口,这样就符合高层不应该依赖低层,应该依赖于接口的依赖倒置原则,修改后代码如下:
用户吃完米饭后想要喝点汤,我们发现 haveDinner() 方法的依赖 Rice 不再适用.此时我们若依赖倒置,将haveDinner与更大范围的Ifood进行依赖,而Rice 和 Soup 实现Ifood接口,就可以解决所述问题.
3 结尾
六大设计原则的首字母联合起来为SOLID-稳定的(两个L合成一个).使用六大设计原则,可以建立灵活健壮的系统.