《邓哥奇遇记9》—— 设计模式之六大基本原则

我们在学习、开发或面试时经常会听到设计模式,很多同学也多多少少能说出一点关于设计模式的东西来,但是很多同学却一直无法理解设计模式的精髓,那么今天开始我们就来聊聊设计模式~
  我们依旧提出几个问题:
  01设计模式和设计原则是什么关系?
  答:所有的设计模式都是遵循设计原则的,不能违反设计原则。
  02设计原则的核心思想是什么?
  核心思想只有两条:减少复杂度(让一个复杂的逻辑变成多个简单的逻辑),降低耦合度(让模块之间的关联减少,使得模块之间更独立、更清晰)
  那么今天我们就来用邓哥的故事来和大家聊聊设计模式的六大基本原则。
  1.单一职责原则
  周末恰逢邓哥休息在家,感受安静的清晨,正准备睡个回笼觉之际,邓嫂将邓哥踢下床对邓哥说:“把屋子扫了,衣服洗了,午饭做了,衣橱整理一下~”
  邓哥只能耷拉着双眼乖乖的去干活。但是邓哥要做的事情太多,所以手忙脚乱的。结果洗衣服没有甩干,洒了一地的水,手沾了水弄湿了衣橱里的衣服,做午饭忘了时间弄糊了。然后只能乖乖的去跪搓衣板。。。
  在这个故事里,邓哥就好比是程序中的一个模块。我们尽量不要在一个模块里写过多的业务逻辑,否则业务逻辑之间可能会相互干扰,引起更多的错误。
  在这个故事中,如果只让邓哥做一件事,估计还是可以做的好的,但是同时让邓哥做这么多的事,就会出现问题。所以单一职责原则的本质就是要将一个复杂的逻辑拆分成多个简单的逻辑,以此来降低复杂度。
  2.里氏代换原则
  邓哥喜欢妹子,可以推出邓哥喜欢邓嫂(因为邓嫂是妹子)。但是邓哥喜欢邓嫂,无法推出邓哥喜欢所有的妹子(主要原因可能是不敢)。
  里氏代换原则的一个核心思想就是父类能做的事、能去的地方,子类必须也能做、也能去。
  从逻辑上举个例子,大前提:我喜欢动物。小前提:大熊猫是动物。结论:我喜欢大熊猫。
  在这个例子中,大熊猫是动物的一种,所以很明显动物是大熊猫的父类,所以对父类成立的逻辑对子类也必然成立。但是反过来,我喜欢大熊猫无法推论出我喜欢动物。所以如果一个方法或模块使用了一个子类,那么这个子类不能用其父类代替。
  里氏代换原则的核心:父亲能做的孩子都能做,孩子能做的父亲不能做,降低耦合度。
  3.开闭原则
  闭原则:邓哥在外边经常受欺负,邓嫂很生气,觉得这样很不合理。于是规定:邓哥只能被邓嫂打,如果有人想要打邓哥,必须和邓嫂说,然后由邓嫂来打邓哥~
  开原则:邓嫂经常觉得邓哥太笨了,琴棋书画不会,洗衣做饭嫌累。所以邓嫂决定让孩子来学习琴棋书画。
  开闭原则的核心就是对修改关闭,对扩展开放。
  就像是在这个例子中,如果谁都能打邓哥就乱套了,所以规定只能由邓嫂来打邓哥,这样方便管理。这就是对修改关闭。
  当我们觉得邓哥的功能太少的时候(琴棋书画不会),我们也不能直接给邓哥增加功能,只能通过扩展的方式(让邓哥的孩子来学)。这样最后总体上邓家就有了会亲戚书画的人了。
  由于里氏代换原则的存在,在需要邓哥的时候,邓哥的孩子可以替代,所以就解决了邓哥不会琴棋书画的问题~开闭原则的核心:对修改关闭,对扩展开发,依次来减少耦合度。
  4.依赖倒置原则
  邓哥每天在家都听邓嫂指挥,终于有一天邓哥硬气了一回~邓哥对邓嫂说:“你每天都命令我做这个做那个,传出去我多没面子~我不要面子的嘛~?”邓嫂想了想觉得邓哥说的确实有道理。于是对邓哥说:“以后每天我就不命令你了~你每天看小纸条吧~小纸条上写什么你就做什么,都是小纸条命令你的,和我就木有关系了~”
  邓哥一想有道理,于是就答应了。从此以后,每天邓嫂都不会对邓哥呼来唤去了~有什么事就往小纸条上写~
  邓哥和邓嫂就相当于程序中的两个函数或者两个模块。原本这两个模块是相互依赖的关系(A调用B)。但是这样会有一个问题,就是当一个模块发生修改的时候,总会对相关模块产生影响,为了降低这种影响,人们决定使用依赖倒置原则来降低核心模块间的耦合度。
  依赖倒置原则的核心:让原来相互依赖的两个核心模块,变为同时依赖于另一个非核心模块。以此来降低核心模块的耦合度。
  5.接口分离原则
  有一天邓哥对邓嫂说:“我想下楼买菜,回家打游戏,晚上吃排骨&……#%&&#*巴拉巴拉一大堆”,邓嫂对邓哥说,一口气说这么多谁听得懂~一件一件说~
  很多的同学在工作初期,喜欢定义一个接口之后,通过传不同的参数做不同的事,最后只有一个接口,但是参数极其复杂。
  就像是这个例子中这样,邓哥虽然只说了一句话,但是内容极其复杂,这样明显增加了系统的复杂度。
  所以我们需要使用接口分离原则,其实接口分离原则和单一职责原则非常的像,就是每个接口负责的内容尽量单一,不要使用复杂的总接口,以此来降低系统的复杂度。
  6.迪米特法则
  邓嫂为了不让邓哥学坏,平时经常告诫邓哥:“不要和陌生人说话~”
  “不要和陌生人说话”就是迪米特法则的精髓所在,迪米特法则指的就是:除了自身,当前对象的成员,参数,当前对象所创建的对象之外,尽量不要与其他外部实体或模块产生关联(引用或调用),以此来降低系统的耦合度。
  最后,六大基本原则才是程序设计的基本原则,我们学习的设计模式只不过是遵循基本原则的比较经典的具体实践。比如工厂模式,符合开闭原则、策略模式符合依赖倒置原则,观察者模式符合依赖倒置原则等等。所以我们在学习的时候,一定要学习知识的本质,不要只学习表象,否则就会出现学了还不会用的情况~

原文地址:https://blog.51cto.com/13409950/2459266

时间: 2024-10-19 03:53:54

《邓哥奇遇记9》—— 设计模式之六大基本原则的相关文章

《邓哥奇遇记5》——同源策略

hello,小伙伴们,又到了<邓哥奇遇记>时间了,是不是很期待呢~好了,咱们闲言少叙,奇遇继续~ 同源策略几乎是前端面试中几乎必然问到的问题.但是很多同学对同源策略的理解不够深入,今天我们就来聊聊同源策略的问题. 首先按照老规矩,我们先来提出几个问题: 1. 什么是同源? 2. 为什么要有同源策略? 一句话解释同源就是:相同协议,相同域名,相同端口称为同源. 下面我们还是用邓哥抄作业的故事来讲述什么是同源策略. 话说邓哥大学时候号称比较"浪漫~",因为很"浪&qu

《邓哥奇遇记8》——域名解析过程

当我们在浏览器的地址栏中输入了一个域名~比如github.com的时候,在我们的计算机中以及整个网络中都会发生什么事情呢? 从我们输入域名开始直到我们获得要访问的ip地址的过程,我们称之为域名解析过程.这个过程也是很多公司面试的时候经常会问的问题,那么我们今天依然通过邓哥的例子来为大家解释域名解析的全过程~ 有一天邓哥想约绿茶妹妹出来玩~打通电话之后,绿茶妹妹说:"那你明天来接我吧~". 这里邓哥想去绿茶妹妹家,就像是我们想访问某个网站,比如百度. 我们说的"绿茶妹妹家&qu

邓哥奇遇记——初识五层网络模型

大家都经常听到Http协议.TCP/IP协议,UDP协议等等很多协议,这都是一些既熟悉又陌生的词,很多同学不理解这些协议是做什么的?好吃吗?不用协议行不行?这些协议有什么区别?今天我们就来聊聊这个话题~为了内容上更趣味性,就说说我身边的人--邓哥. 话说邓哥平生,稳久必浪,浪久必稳.有一天,你们成哥给邓哥介绍了一个女朋友,名叫:赵铁锤~邓哥虽然平时抽烟喝酒烫头,但是性格还是比较内向的~所以决定先进行书信交流~ 这时邓哥和铁锤妹妹就相当于两个软件或者两个程序,邓哥想给铁锤妹妹送信,就好像是两个软件

《邓哥奇遇记7》—— GET与POST的真正区别

我们会经常看到有人问:http协议中GET请求和POST请求有什么区别~? 这个问题看似很简单,但是不同程度的人会回答出不同的结果.在公司的面试中,也会经常的问及类似这样的问题,看似很简单,但是不同层次的人会回答出不同的结果.那么我们今天就来聊聊HTTP协议中GET与POST的真正区别. 我们还是要用一句简练的话来回答GET和POST的区别: 提及GET和POST的区别,一定要确定基于什么前提.在不同的前提下有不同的答案. 这么简单的GET和POST背后有什么神秘的面纱呢?我们今天依然用邓哥的例

《邓哥奇遇记3》——TCP三次握手

你是否经常听别人提起TCP的三次握手和四次挥手呢?你是否看过很多次关于三次握手和四次挥手的文章都没用看懂或是没有记住?三次握手与四次挥手是计算机行业的一个基本知识点,无论是校招还是社招.无论是前端还是后端都有可能被问到,由于很多同学就要开始准备校招了,那么我们今天就先来聊聊TCP的三次握手.我们先来聊聊三次握手,我们看到这个问题的时候,第一个疑问是,啥叫握手?俩机器之间怎么还能握手呢?我怎么没发现我家电脑有手?第二个疑问是,为啥要三次?两次不行吗?我觉得握一下就行了~为啥要握三次?我们今天先用邓

面向对象六大基本原则的理解

在学习设计模式的时候,总是被推荐先学习一下面向对象的六大原则,学习后果然受益匪浅.以下完全是我对六大基本原则的理解,和官网解释可能有出路,而且我更多是站在设计模式的角度,而不是面向对象的角度理解,如果有什么错误,敬亲谅解. 1.开闭原则 很多教程都把开闭原则作为这六大原则中最基本的原则,也就是说他是各个原则的核心.开闭原则指的是,一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 至于这个具体怎么理解,我也看了很多教程,有些教程说当我们遇到新的需求,就需要我们对我们模块继承的形式进行扩展,

设计模式的六大原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

设计模式之六大设计原则

在上篇博文中提到了开放-封闭原则,没有细谈,这次我们来总结一下设计模式的几大原则. 1开放-封闭原则:是指软件实体(类.模块.函数等)应该可以扩展,但是不可修改. 对原则的理解:开闭原则是最具有理想主义色彩的一个原则,它是面向对象设计的终极目标,下面所要介绍的几个原则可以看成是为了符合开闭原则所作的努力和解决办法.对于开闭原则通俗的理解就是,能不改就不改,能少改尽可能的少改.周所周知,物质是运动的,世界是变化的,想要让一个事物永恒不变是不可能的,所以要想让软件绝对符合开闭原则是不可能的. 2单一

bzoj3157国王奇遇记(秦九韶算法+矩乘)

bz第233题,用一种233333333的做法过掉了(为啥我YY出一个算法来就是全网最慢的啊...) 题意:求sigma{(i^m)*(m^i),1<=i<=n},n<=10^9,m<=200 别人的做法: O(m^2logn),O(m^2),甚至O(m)的神做法 学渣的做法:矩乘+秦九韶算法,O(m^3logn),刚好可以过最弱版本的国王奇遇记的数据 (极限数据单点其实是1.2s+,不想继续卡常了-bzoj卡总时限使人懒惰-如果把矩乘的封装拆掉可能会快点吧,然而人弱懒得拆了...