前言

随着计算机行业的不断发展，人们对于可以给予自身快速成长的技术非常的痴迷。就比如今天要聊的设计模式，学过编程的都知道设计模式，而很少有人会知道它的核心思想是什么，只是一味的照着网络上流行的设计模式二十三式依葫芦画瓢。仅做到了知其然而不知其所以然。所以今天来聊聊它出现的意义什么

意义

我们知道一个江湖的组成是非常不容易的，在江湖中也会有很多的门派与帮派，而门派一多就会有各式各样的问题，这时就出来了一个叫做设计模式的东西，来处理门派在发展过程中遇到的一般问题的解决方案。其中的话有以下五经可供参考。

五经

设计模式架构中，有常用来指导设计的 5 大原则，俗称：SOLID

单一原则（SRP）

开闭原则 (OCP)

里氏替换原则 (LSP)

接口隔离原则 (ISP)

依赖倒置原则 (DIP)

单一原则

从字面上理解单一的意思可能就代表着你门派业务或者任务的单一等等，比如龙门镖局的创立之初可能就是说押押镖送送快递之类的。而药仙谷则可能就只是制制药之类的。它们俩之间就不存在什么耦合性关系了。

翻译：一个类只负责完成一个职责或者功能。一个模块应该对一类且仅对一类行为者负责。不要设计大而全的类，要设计粒度小、功能单一的类。单一职责原则是为了实现代码高内聚、低耦合、提高代码的复用性、可读性、可维护性。

判断是否单一：

类中的代码行数、函数或者属性过多；

类依赖的其他类过多，或者依赖类的其他类过多；

私有方法过多；

比较难起一个合适的名字；

类中大量的方法都是集中操作类中的某几个属性。

误区： 类与模块的划分不是说划分越细越好的，因为拆分的过细，会降低内聚性，增加维护的成本

建议： 在划分类与模块时，尽量从业务出发。而且划分的过程也可以是跟着业务的发展逐步进行的。

 // 错误的示范 可以看到客户类当中加入了支付的相关逻辑，明显不单一class Customer{public function getCustomer(){echo '客户信息';}public function pay(){echo '支付金额';}}// 正确示范 将客户的正常信息与支付信息划分开class Customer{public function getCustomer(){echo '客户信息';}}class CustomerPay{public function pay(){echo '支付金额';}}

开闭原则

随着门派的不断发展，客户量的不断增加，就会有许多扩张方案或者活动之类。就拿龙门镖局为例：周年庆时，门派为了酬谢客户而举办了一个活动。这个活动由于是新的业务，为了不影响旧的业务的进行，门派就新扩展了一个活动部门专门处理周年庆的事情。

翻译：软件实体（模块、类、方法等）应该对“对扩展开发、对修改关闭”，也可这样理解那就是添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）

注意点：

开闭原则并不是完全杜绝修改，而是以最小的代价完成新功能的开发

在不同角度来看，修改也可能是扩展。粗粒度下可能是修改，细粒度来看可能是扩展。

里式替换

随着活动办的非常成功，门派业务也是突飞猛进，所以门主及长老打算在荆州再开一个分局，但是分局的相关规章制度是一样的。

翻译：子对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏

违反了里式替换:

子类违背父类声明要实现的功能

子类违背父类对输入、输出、异常的约定

子类违背父类注释中所罗列的任何特殊说明

注意点：
1.父类定义了函数的“约定”（或者协议），那么子类可以改变函数的内部实现逻辑，但不能改变原有的“约定”，比如：输入、输出、异常的约定甚至包括注释。

接口隔离

在门派创立之初，发布了一个入门申请的规范，只要满足实现了规范上写的就可以龙门镖局了。可是有一天掌门想添加一条关于清退不合格人员，但是如果在入门那个规范里面写就不太好了所以重新发了一份清退规范。

翻译：客户端不应该强迫依赖它不需要的接口，其中的“客户端”可以理解为接口的调用者或者使用者

接口定义：

一组API接口集合

单个API接口或函数

OOP中的接口概念

注意点：

接口需要单一，不该让接口的实现类和调用者，依赖不需要的接口函数。

依赖倒置

在第三方招人机构没有发展之前，门派的招人都是自主招人发工资的，而这时候门派与员工必须强耦合了，而这时候第三方人力公司搞出来个劳务派遣，雇主把钱给到人力公司，人力公司去招人并发工资给员工，通过这样的方式，雇佣双方把对方的直接控制，反转到了让对方来依赖一个标准的派遣模型的接口——人力公司。

翻译：高层模块不要依赖底层模块，高层模块和低层模块应该通过抽象来互相依赖。除此之外，抽象不要依赖具体实现细节，具体实现细节依赖抽象。

ps：在调用链上，调用者属于高层，被调用者属于低层。

设计模式之内功心法 SOLID五大原则相关推荐

solid 设计原则 php,面向对象设计SOLID五大原则
今天我给大家带来的是面向对象设计SOLID五大原则的经典解说. 我们知道,面向对象对于设计出高扩展性.高复用性.高可维护性的软件起到很大的作用.我们常说的SOLID五大设计原则指的就是: S = 单一 ...
SOLID五大原则【图解】
目录前序五大基本原则-SOLID 1. SRP 2. OCP 3. LSP 4. ISP 5. DIP 参考链接前序做C语言开发的应该都知道,C是面向过程开发的,而c++是面向对象开发的.而封 ...
设计模式：面向对象的设计原则下（ISP、DIP、KISS、YAGNI、DRY、LOD）
本文继续来介绍接口隔离原则(ISP)和依赖倒置原则(DIP),这两个原则都和接口和继承有关.文章最后会简单介绍几个除了 SOLID 原则之外的原则. 接口隔离原则(ISP) 提起接口,开发人员的第一反 ...
设计模式原则(单一、开放封闭、里氏代换、依赖倒转、迪米特法则五大原则)...
原文:设计模式原则(单一.开放封闭.里氏代换.依赖倒转.迪米特法则五大原则) 单一职责原则单一职责原则,就一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦 ...
关于设计模式五大原则
什么是设计模式设计模式是一种应对多场景或者复杂的业务场景的一种工具,有利于代码的复用/维护,系统模块的组织和设计的沟通设计模式五大原则开闭原则开闭原则(OCP: open closed pri ...
23种设计模式分类+SOLID设计原则+从设计模式角度看MVC框架
目的:设计模式旨在帮助使用者设计可维护.可扩展.可复用.灵活性好的系统 1. 23中设计模式分类 1.1 创建型模式(5个) 工厂方法模式(Factory Method) 抽象工厂模式 (Abstr ...
软件开发、设计、架构的五大原则
唯一不变的就是变化本身. 我们经常讲的系统.子系统.模块.组件.类.函数就是从逻辑上将软件一步步分解为更细微的部分,即逻辑单元, 分而治之, 复杂问题拆解为若干简单问题, 逐个解决. 逻辑单元内部.外 ...
SOLID 设计原则 In C# 代码实现
[S] Single Responsibility Principle (单一职责原则) 认为一个对象应该仅只有一个单一的职责 namespace SingleResponsibilityPrinci ...
PHP面向对象设计的五大原则
面向对象设计的五大原则:单一职责原则.接口隔离原则.开放-封闭原则.替换原则.依赖倒置原则.这些原则主要是由Robert C.Martin在<敏捷软件开发--原则.方法.与实践>一书中总结 ...

设计模式之内功心法 SOLID五大原则

内功心法

前言

意义

五经

单一原则

开闭原则

里式替换

接口隔离

依赖倒置

设计模式之内功心法 SOLID五大原则相关推荐

最新文章

热门文章