专栏首页星流全栈什么是「设计模式」?

什么是「设计模式」?

很多人应该听说过设计模式(Design pattern),又或多或少的看过或用过设计模式,但是实际用在开发过程中总有点心有余而力不足的感觉。那肯定是对设计模式的理解有少许偏差或者不够深入。先不谈某种具体的模式,先来看看什么是设计模式?本文从概论结合实际场景进行了分析。

什么是设计模式?

设计模式是一套代码设计「经验的总结」。项目中「合理的」运用设计模式可以「巧妙的解决很多问题」。

  • 经验的总结:抱着「代码虐我千百遍,我待代码如初恋」的心态,最终得出来的「套路」。
  • 合理的:要对设计模式的使用场景有一定的认识后才使用,「不要滥用」。如:输出一句“hello world”,非要强行给加上各种模式。
  • 问:“为什么”,答:“总感觉少了模式!”。
  • 巧妙的解决了很多问题:被广泛应用的原因。

为什么要提倡“Design Pattern呢?根本原因是为了代码复用,增加可维护性。那么怎么才能实现代码复用呢?

设计模式之六大原则

开闭原则(Open Close Principle)

1988年,勃兰特·梅耶(Bertrand Meyer)在他的著作《面向对象软件构造(Object Oriented Software Construction)》中提出了开闭原则,它的原文是这样:“Software entities should be open for extension,but closed for modification”。

  • 意思:软件模块应该对扩展开放,对修改关闭。
  • 举例:在程序需要进行新增功能的时候,不能去修改原有的代码,而是新增代码,实现一个热插拔的效果(热插拔:灵活的去除或添加功能,不影响到原有的功能)。
  • 目的:为了使程序的扩展性好,易于维护和升级。

里氏代换原则(Liskov Substitution Principle)

  • 意思:里氏代换原则是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。
  • 举例:球类,原本是一种体育用品,它的衍生类有篮球、足球、排球、羽毛球等等,如果衍生类替换了基类的原本方法,如把体育用品改成了食用品(那么软件单位的功能受到影响),就不符合里氏代换原则。
  • 目的:对实现抽象化的具体步骤的规范。

依赖倒转原则(Dependence Inversion Principle)

  • 意思:针对接口编程,而不是针对实现编程。
  • 举例:以计算机系统为例,无论主板、CPU、内存、硬件都是在针对接口设计的,如果针对实现来设计,内存就要对应到针对某个品牌的主板,那么会出现换内存需要把主板也换掉的尴尬。
  • 目的:降低模块间的耦合。

接口隔离原则(Interface Segregation Principle)

  • 使用多个隔离的接口,比使用单个接口要好。
  • 举例:比如:登录,注册时属于用户模块的两个接口,比写成一个接口好。
  • 目的:提高程序设计灵活性。

迪米特法则(最少知道原则)(Demeter Principle)

1987年秋天由美国Northeastern University的Ian Holland提出,被UML的创始者之一[Booch]等普及。后来,因为在经典著作《 The Pragmatic Programmer》而广为人知。

  • 意思:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。
  • 举例:一个类公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险扩散也就越大。
  • 目的:降低类之间的耦合,减少对其他类的依赖。

单一职责原则( Single responsibility principle )

该原则由罗伯特·C·马丁(Robert C. Martin)于《敏捷软件开发:原则、模式和实践》一书中给出的。马丁表示此原则是基于汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著作中的内聚性原则发展出的。

  • 意思:一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。
  • 举例:该原则意思简单到不需要举例!
  • 目的:类的复杂性降低,可读性提高,可维护性提高。

刚入行的时候,在想什么样的代码是好代码?看到很多前辈的文字都说好的代码要符合「高内聚,低耦合」,但是我听到这样的解释,是这样的

递归懵逼

而现在对设计模式有了一定程度上的学习,感觉懂了一些,小伙伴们你们学会了吗?

高内聚,低耦合?

  • 内聚是从功能角度来度量模块内的联系,一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系;
  • 耦合是软件结构中各模块之间相互连接的一种度量,耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。

本文来自简书陈宇明,点击阅读原文查看。

本文分享自微信公众号 - 星流全栈(MeteorFullStack),作者:陈宇明

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-05-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Meteor1.3七日谈 — Mantra核心简介

    时见疏星
  • 2017,忘掉「全栈」,迎向「一栈」!

    时见疏星
  • 地平线之旅 — Horizon初探

    时见疏星
  • 【游戏开发】浅谈游戏开发中常见的设计原则

      俗话说得好:“设计模式,常读常新~”。的确,每读一遍设计模式都会有些新的体会和收获。马三不才,才读了两遍设计模式(还有一遍是在学校学的),属于菜鸟级别的。这...

    马三小伙儿
  • 分享一款炒鸡好用的网盘+文件服务器

    在之前的图床开发中撸主曾使用了分布式文件服务FASTDFS和阿里云的OSS对象存储来存储妹子图。奈何OSS太贵,FASTDFS搭建配置又太繁琐,今天给大家推荐一...

    小柒2012
  • React的小案例:&&运算符、元素变量、三目运算符与React的条件渲染都在这里了

    用户1272076
  • SpringBoot 2.x 开发案例之整合MinIo文件服务

    在之前的图床开发中撸主曾使用了分布式文件服务FASTDFS和阿里云的OSS对象存储来存储妹子图。奈何OSS太贵,FASTDFS搭建配置又太繁琐,今天给大家推荐一...

    小柒2012
  • 干货 | 初学者入门必看的“知识图谱”解读(中)

    本系列参考了市面上已知的,几乎全部“知识图谱”相关文章,并总结提炼出一套适合初学者入门的“知识图谱”的知识体系,希望大家能有所收获。

    AI研习社
  • 浅谈 Node.js 模块机制及常见面试问题解答

    Node.js 模块机制采用了 Commonjs 规范,弥补了当前 JavaScript 开发大型应用没有标准的缺陷,类似于 Java 中的类文件,Python...

    用户1462769
  • 资源 | 工程师必备!最好的九张机器学习&深度学习代码速查表

    作者在 Github 上建立了一个代码速查表,对机器学习初学者来说是不可多得的一个资源。机器之心将文章中的高清图片下载到了百度网盘,读者可从中浏览,也可以点击项...

    用户2769421

扫码关注云+社区

领取腾讯云代金券