php设计模式之六大设计原则】的更多相关文章

定义 一个软件实体(如类.模块.函数)应当对扩展开放,对修改关闭. 定义解读 在项目开发的时候,都不能指望需求是确定不变化的,大部分情况下,需求是变化的.那么如何应对需求变化的情况?这就是开放-关闭原则要谈的. 开放-封闭原则的思想就是设计的时候,尽量让设计的类做好后就不再修改,如果有新的需求,通过新加类的方式来满足,而不去修改现有的类(代码).那么在实际的项目开发中,是否能做到绝对的对修改关闭呢?答案一般也是否定的.既然这样,那么就要求我们在开发前,去找出变化点,然后针对变化点构造抽象,隔离出…
PHP设计模式的六大设计原则 1 简介 软件设计最大的难题就是应对需求的变化,但是纷繁复杂的需求变化却是不可预料的.此时,我们可以通过六大设计原则良好的应对未来的变化. 2 讲解 2.1 单一职责原则(Single Responsibility Principle) 一个类只负责一个职责 简单的例子,用户发送一个请求到服务器,当我们所有的操作只用一个action类来完成 <?php $action = new action; $action->getResp(); class action{…
定义 就一个类而言,应该仅有一个引起它变化的原因. 定义解读 这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作. 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多: 类的可读性增强,阅读起来轻松: 可维护性强,一个易读.简单的类自然也容易维护: 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响. 问题提出 假设有一个类C,它负责两个不同的职责:职责P1和…
定义 狭义的迪米特法则定义:也叫最少知识原则(LKP,Least Knowledge Principle).如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用.如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用. 广义的迪米特法则定义:一个模块设计得好坏的一个重要的标志就是该模块在多大的程度上将自己的内部数据与实现有关的细节隐藏起来.信息的隐藏非常重要的原因在于,它可以使各个子系统之间脱耦,从而允许它们独立地被开发.优化.使用阅读以及修改. 定义解读 迪…
  1.单一职责 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 场景:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 修改:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 优点: 1).可以降低类的复杂度,一个类只负责一项职责,逻辑简单…
定义 高层模块不应该依赖于低层模块,二者都应该依赖于抽象:抽象不应该依赖细节:细节应该依赖抽象. 定义解读 依赖倒置原则在程序编码中经常运用,其核心思想就是面向接口编程,高层模块不应该依赖低层模块(原子操作的模块),两者都应该依赖于抽象.我们平时常说的“针对接口编程,不要针对实现编程”就是依赖倒转原则的最好体现:接口(也可以是抽象类)就是一种抽象,只要不修改接口声明,大家可以放心大胆调用,至于接口的内部实现则无需关心,可以随便重构.这里,接口就是抽象,而接口的实现就是细节. 如果不管高层模块还是…
定义 客户端不应该依赖它不需要的接口: 一个类对另一个类的依赖应该建立在最小的接口上. 定义解读 定义包含三层含义: 一个类对另一个类的依赖应该建立在最小的接口上: 一个接口代表一个角色,不应该将不同的角色都交给一个接口,因为这样可能会形成一个臃肿的大接口: 不应该强迫客户依赖它们从来不用的方法. 接口隔离原则有点像单一职责原则,但是也有区别,在单一职责原则中,一个接口可能有多个方法,提供给多种不同的调用者所调用,但是它们始终完成同一种功能,因此它们符合单一职责原则,却不符合接口隔离原则,因为这…
定义 里氏替换原则的定义有两种,据说是由麻省理工的一位姓里的女士所提出,因此以其名进行命名. 定义1:如果对一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1所定义的程序P中在o1全都替换成o2时,程序的行为不发生任何变化,那么T2为T1的子类. 定义2:所有引用父类的地方都必须能够透明地使用其子类对象. 定义解读 其实两个定义所表达的意思都相同,就是在所有父类出现的地方,子类都可以出现,并且将父类对象替换为子类对象的时候,程序不会抛出任何异常或者错误,因此我们需要注意的是,尽量不要…
定义 一个软件实体(如类.模块.函数)应当对扩展开放,对修改关闭. 定义解读 在项目开发的时候,都不能指望需求是确定不变化的,大部分情况下,需求是变化的.那么如何应对需求变化的情况?这就是开放-关闭原则要谈的. 开放-封闭原则的思想就是设计的时候,尽量让设计的类做好后就不再修改,如果有新的需求,通过新加类的方式来满足,而不去修改现有的类(代码).那么在实际的项目开发中,是否能做到绝对的对修改关闭呢?答案一般也是否定的.既然这样,那么就要求我们在开发前,去找出变化点,然后针对变化点构造抽象,隔离出…
  先看一幅图吧: 这幅图清晰地表达了六大设计原则,但仅限于它们叫什么名字而已,它们具体是什么意思呢?下面我将从原文.译文.理解.应用,这四个方面分别进行阐述. 1.单一职责原则(Single Responsibility Principle - SRP) 原文:There should never be more than one reason for a class to change. 译文:永远不应该有多于一个原因来改变某个类. 理解:对于一个类而言,应该仅有一个引起它变化的原因.说白了…
[有格式的原文请到https://www.cnc6.cn/c六大设计原则/文末下载] 软件设计原则常见的有6大原则,分别为: ①单一职责原则: ②开闭原则: ③依赖倒置原则: ④里氏替换原则: ⑤接口隔离原则: ⑥迪米特法则. 使用C#编程方式,并结合仪器(Instrument)编程,对以上设计原则进行讲解. 一.单一职责原则 简述:类职责要单一,不能有多个职责,具有多个职责的类要进行拆分,形成单一职责的类. C#代码如下: class DCPowerSupply { public void O…
从今年的七月份开始学习设计模式到9月底,设计模式全部学完了,在学习期间,总共过了两篇:第一篇看完设计模式后,感觉只是脑子里面有印象但无法言语.于是决定在看一篇,到9月份第二篇设计模式总于看完了,这一篇看完,脑子里面已经能够对绝大多数的设计模式能够说出其核心思想且可以画出类图也知道应用场景,算是一个进步,但可能还不能够特别熟练的使用,可能需要多多巩固和强化使用才能够完全理解设计模式的精髓所在.学习期间收获还是不少的: 1.从只听过设计模式到学习了所有的设计模式,并写了不少设计模式的博客,在公司期间…
类的设计原则     依赖倒置原则-Dependency Inversion Principle (DIP) 里氏替换原则-Liskov Substitution Principle (LSP) 接口分隔原则-Interface Segregation Principle (ISP) 单一职责原则-Single Responsibility Principle (SRP) 开闭原则-The Open-Closed Principle (OCP) 一. Dependency Inversion P…
声明:本文内容是从网络书籍整理而来,并非原创. 用户管理的例子 先看一张用户管理的类图:  再看一眼上面的图,思考:这样合理吗? 这个接口是一个很糟糕的设计! 用户的属性和行为竟然混合在一起!!! 正确的做法是把用户的信息抽取成一个业务对象(Bussiness Object,简称 BO),把行为抽取成另外一个接口中,我们把这个类图重新画一下:  这样划分成了两个接口,IUserBO 负责用户的属性,IUserBiz 负责用户的行为,因为是面向的接口编程,所有当产生了这个 UserInfo 对象之…
创建型模式 抽象工厂模式(Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类. 生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示. 工厂模式(factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是哪一个. 工厂方法让类把实例化推迟到子类. 原型模…
为什么要有设计原则,我觉得一张图片就可以解释这一切 一.单一职责原则(SRP) 对于一个类而言,应该只有一个发生变化的原因.(单一职责不仅仅是指类) 如果一个模块需要修改,它肯定是有原因的,除此原因之外,如果遇到了其他情况,还需要对此模块做出修改的话,那么就说这个模块就兼具多个职责.举个栗子: 此时我们有个动物类Animal,有个Move()会移动的方法 public class Animal { //动物移动的方法 public void Move(String name) { Console…
单一职责原则SRP(Single reponsibility principle) BO(Business Object):业务对象 Biz(Business Logic):业务逻辑 SRP最简单的例子:用户信息维护类 单一职责原则SRP定义 应该有且仅有一个原因引起类的变更.(一个接口只有一个职责) SRP例子:电话通话过程 电话通话的过程:拨号.通话.回应.挂断. 如果按照一定职责进行划分:可以分为协议管理和数据传送. 协议管理:拨号和挂机. 数据传送:通话. 这个类中包含两个职责,但是拨号…
ISP的定义 首先明确接口定义 实例接口 我们在Java中,一个类用New关键字来创建一个实例.抛开Java语言我们其实也可以称为接口.假设Person zhangsan = new Person();我们称Person类就是张三的接口类. 类接口 Java中用interface定义的接口. 其次明确隔离定义 客户端不应该依赖他不需要的接口. 类间的依赖关系应当建立在最小的接口上. 首先第一种说明客户端依赖接口,依赖的接口不能过于臃肿,所以要进行细化.第二种定义也是要求接口进行细化,保持接口的纯…
SOLID (面向对象设计) 单一功能原则(Single responsibility principle) 每个类都应该有一个单一的功能,并且该功能应该由这个类完全封装起来 所有它的(这个类的)服务都应该严密的和该功能平行(功能平行,意味着没有依赖). 开闭原则(Open Closed Principle) 软件中的对象(类,模块,函数等等)应该对于扩展是开放的,但是对于修改是封闭的 里氏代换原则(Liskov Substitution Principle LSP) 任何基类可以出现的地方,子…
依赖倒置原则DIP(Dependence Inversion Principle) 依赖倒置原则的含义 高层模块不能依赖低层模块,二者都应该依赖其抽象. 抽象不应该依赖于细节. 细节应该依赖抽象. 什么是高层模块?低层模块? 每一个原子逻辑就是低层模块,原子逻辑再组就是高层模块. 什么是抽象和细节? 抽象是抽象类,不可被实例化. 细节是实现类,比如实现的接口或继承抽象类的子类,可以被实例化. 表现在Java语言中就是面向接口编程 模块间的依赖是通过抽象来实现的,具体的实现类之间不能发生直接的依赖…
里氏替换原则LSP(Liskov Subsituation Principle) 里氏替换原则定义 所有父类出现的地方可以使用子类替换并不会出现错误或异常,但是反之子类出现的地方不一定能用父类替换. LSP的四层含义 子类必须完全实现父类的方法 子类可以自己的个性(属性和方法) 覆盖或实现父类的方法时输入参数可以被放大 覆盖或实现父类的方法时输出结果可以被缩小 LSP的定义含义1--子类必须完全实现父类的方法 假设如下场景:定义一个枪支抽象类,一个场景类,三个枪支实现类,一个士兵类.此处,三个枪…
设计模式之六大原则(转载) 关于设计模式的六大设计原则的资料网上很多,但是很多地方解释地都太过于笼统化,我也找了很多资料来看,发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂,因此转载过来. 原作者博客链接:http://blog.csdn.net/LoveLion/article/category/738450/7 一.单一职责原则 原文链接:http://blog.csdn.net/lovelion/article/details/7536542 单一职责原则是最简单的面向对象设…
在之前的java 23 中,了解过设计模式的单例模式和工厂模式.在这里,介绍下设计模式 面向对象思想设计原则 在实际的开发中,我们要想更深入的了解面向对象思想,就必须熟悉前人总结过的面向对象的思想的设计原则 单一职责原则 开闭原则 里氏替换原则 依赖注入原则 接口分离原则 迪米特原则 单一职责原则 其实就是开发人员经常说的"高内聚,低耦合" 也就是说,每个类应该只有一个职责,对外只能提供一种功能,而引起类变化的原因应该只有一个.在设计模式中,所有的设计模式都遵循这一原则. 开闭原则 核…
面向对象 现在,主流的编程范式或者是编程风格有三种,它们分别是面向过程.面向对象和函数式编程.面向对象这种编程风格又是这其中最主流的.现在比较流行的编程语言大部分都是面向对象编程语言.大部分项目也都是基于面向对象编程风格开发的.面向对象编程因为其具有丰富的特性(封装.抽象.继承.多态),可以实现很多复杂的设计思路,是很多设计原则.设计模式编码实现的基础. 所以,在专栏的最开始,我们会详细地讲解面向对象编程的相关的知识,为学习后面的内容做铺垫.对于这部分内容,你需要掌握下面这 7 个大的知识点.…
Design Principle设计原则 最近由于碰到要参与设计一个音频处理系统,有人提议用一个大的全局变量结构体来做状态信息交流的地方,引起了我对设计一个系统的思考,于是找到了如下资料,当然,关于这个系统也是有待验证,不能说全局变量就是不好,因为这个系统并不会并发执行,而且资源充足. 我反正有点疑虑,但是会继续验证. 以下为Gof的六大设计原则,出自<设计模式>. Single Responsibility Principle -SRP There should never be more…
内容总览 六大设计原则都有哪些 一.单一职责原则 二.里氏替换原则 三.依赖倒置原则 四.接口隔离原则 五.迪米特法则 六.开放封闭原则 内容详解 一.单一职责原则 单一职责原则:英文名称是Single Responsiblity Principle,简称是SRP.定义:应该有且仅有一个原因引起类的变更. 单一职责原则要求:一个接口或类只有一个原因引起变化,也就是一个接口或类只有一个职责,它就负责一件事情. 单一职责原则的好处: 类的复杂性降低,实现什么职责都有清晰明确的定义: 可读性提高,复杂…
1.外观模式(Facade) 一层一层向上封装,灵活性会降低,功能完成度高,和python的模块比较像,但对于封装好了的类,将会变得很简单,简洁. 2.六大设计原则 单一职责原则 (Single Responsibility Principle) 一个类直负责一项职责(操作).一个类,只应该有一个引起它变化的原因. 里氏替换原则 (Liskov Substitution Principle) 所有引用基类的地方必须能透明地使用其子类的对象.(子类父类) 子类可以实现父类的抽象方法,但不能覆盖父类…
设计模式之六大原则——接口隔离原则(ISP)  转载于:http://www.cnblogs.com/muzongyan/archive/2010/08/04/1792528.html 接口隔离原则 Interface Segregation Principle    定义: 客户端不应该依赖它不需要的接口 类间的依赖关系应该建立在最小的接口上 我们可以把这两个定义概括为一句话:建立单一接口,不要建立臃肿庞大的接口.再通俗一点讲:接口尽量细化,同时接口中的方法尽量少. 提供给每个模块的都应该是单…
一.总体来说设计模式分为三大类: 创建型模式:对象的创建. 创建对象本身是比较耗时的操作,所以我们这里专门找人来帮我们创建对象,我们根据经验总结出来的设计成熟的思路模式. 结构型模式:对象的组成(结构). 行为型模式:  对象的行为. 创建型模式,共六种:简单工厂模式,工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式. 结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式.组合模式.享元模式. 行为型模式,共十种:模版方法模式.观察者模式.状态模式.职责链模式.命令…
Java 设计模式(二)-六大原则 单一职责原则(Single Responsibility Principle) 定义: 不要存在多余一个原因导致类变更,既一个类只负责一项职责. 问题由来: 当类A有两个不同职责P1和P2时,当类A的职责P1需要修改时,可能影响职责P2的功能不能正常运行. 解决方案: 将类A分为类A1和类A2,A1的职责时P1,A2的职责是P2,此时修改P1或P2职责都不影响另一职责. 优点: 降低类负责度 降低变更引起的风险 提高类的可读性 提高系统的可维护性 里氏替换原则…