时间:2021-07-01 10:21:17 帮助过:23人阅读
前言
这篇文章是我写完三种设计模式之后才写的,究其原因呢,是由于今天get到了一些更为设计模式原则的东西,不管是设计模式还是大家平时写的代码,都会无意中用到何遵守的,我打算用自己的话来写一遍。
你不知道的设计模式原则
定义
不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。
白话文理解
能分工协作的尽量分好工,各自负责自己的一块,并且把它做好就好了,避免相互影响。
定义
所有引用基类的地方必须能透明地使用其子类的对象,也就是说子类可以扩展父类的功能,但不能改变父类原有的功能
白话文理解
当要继承前人写的类的时候,尽量不重写和重载里面的方法,因为你根本不知道,哪里会被影响到。继承方法也尽量尊重原逻辑不轻易改变。
定义
高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。
白话文理解
父亲模块不和其子模块相互依赖,最好都依赖第三方(抽象的类),可以避免高耦合的坑,万一产品改策略,也可以轻松通过横向扩展(再来一个继承抽象类的子类)来解决,继承的话遵循里氏代换原则
定义
客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
白话文理解
如果是通过接口进行编程的,不要将一堆抽象的方法放在接口类中,这样会造成继承的类还要去实现根本不属于它的方法,即使是接口,也尽量按照总分的概念去勾划,共用的写在一个接口类中,个别定制的应单独写,子类选择性继承接口类就好。
定义
一个对象应该对其他对象保持最少的了解。
白话文理解
典型的知道了太多更容易死的道理,放在代码里就是,写一个模块的时候尽量能分就分,一个模块包含越多耦合越大,越容易出错,拆成各自独立模块,即使出问题也不会全盘崩。
定义
一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
白话文理解
当产品需求变化时,尽量通过扩展软件实体的行为来实现变化(加类,加方法),而不是通过修改已有的代码来实现变化。
一个问题的讨论
很多优化的地方都在说:高内聚低耦合,那么问题来了,高内聚低耦合真的好吗?
我的看法是:看业务的具体逻辑,因为高内聚低耦合的话,一旦某一块业务相互关联又比较复杂,会直接导致很多独立的代码块存在,即使有备注,看起代码会给人一种跳来跳去的感觉,阅读性会降低,直接导致维护性会降低,当代码接手给别人时候,后人将在理解代码方面花费很多时候,寸步难行。听说适当的耦合代码和按具体依赖关系分块更配哦~
单纯的按照前人总结的抽象的规范写代码也是不对的,好的设计模式是一步一步改出来的,而不是一开始就设计好的。
').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($('').text(i)); }; $numbering.fadeIn(1700); }); });欢迎留言分享
以上就介绍了一看就懂系列之 php设计模式零,包括了方面的内容,希望对PHP教程有兴趣的朋友有所帮助。