设计模式 - 基本功的重要性

简介: 设计模式 - 基本功的重要性

248667912046641316.jpg

基本功


代码质量既是设计出来的,也是迭代优化出来的。换句话说,无论是前期的产品需求分析、架构设计,还是后期的详细代码设计与编码,都离不开良好的设计。


程序设计是每个程序员的基本功。但是,大多数人都只是对新技术充满热情,却很少有人愿意沉下心来,花几个月甚至一两年的时间来重温基础知识,修炼基本功。


在面对所谓“新技术”的浪潮下,一直看不透背后隐藏的朴实规律,只是东一榔头西一棒槌地在原地踏步。


当我真正亲身参与到编码实践和设计中后,才猛然发现设计模式的诸多优势,比如,提升源码阅读效率,快速解决短期项目中的问题,降低维护成本等。

而在不断学习与实践设计模式的过程中收获了很多实打实的经验,包括编程的技巧、架构设计的启发、面试技巧等


如何学好设计模式


有了学习设计模式的目标之后,还得找对学习设计模式的正确方法。

学习设计模式最有效的办法就是:主动学习+刻意练习


在实际工作中,很少有人告诉你一个程序该如何设计,他们只会要求有一个结果——做出一个好的程序并能运行起来。


面对这样的要求,你常常只能处于被动学习状态:任务里需要什么你才学习什么,东一榔头,西一棒槌。这样短期虽然有效,但是长期下来,你的知识积累速度其实很慢。所以,要想学好设计模式,你就得放弃这种被动学习的方式,要有目标、有系统地去主动学习:找寻好的资料,分析理解,开放思维。


是不是还有以下疑惑?


在面试中时常被问到设计模式,可实际工作中却很少使用;


每个模式的样例代码都很熟悉,实际编码时却总感觉力不从心,实现困难;


很多系统设计看上去和很多模式都很像,却不知道到底该用一个模式,还是多个模式;


设计模式除了在编码阶段有用外,在设计上似乎用处并不大。


其实,当时这些困惑的关键并不在于设计模式过于抽象或应用有难度,而在于我可能从一开始就没有搞清楚设计模式的应用范围和背景:设计模式到底解决什么问题?为什么要抽象这样的场景?又是如何解决这些问题的?


对设计模式常见的误解


正因为没有搞清楚这些应用范围和背景,才导致大多数时候我们总是在“生搬硬套”设计模式,以为在应用设计模式,却不知道还没入门就一直在误解设计模式,并无法控制地胡乱使用,最后反而引入了很多不必要的麻烦。

因此,要想学好设计模式,就得摘去这些误解。


误解一:经典模式太抽象,很难学下去


说到设计模式,你的第一反应是不是会想起“四人帮”GoF 的那本“经典”著作《设计模式:可复用面向对象软件的基础》?或者想起那 23 个“经典”的模式?


的确,设计模式太过于经典了,但是经典也会带来一个问题:过于抽象,难以快速理解。而对于业余时间本就不多的你来说,读抽象的经典更是一件难上加难的事。


简单来说,设计模式从不同项目中总结出来的通用经验,是为了帮助我们快速理解现有的系统,并从中找出共性规律,如果没有足够的经验或者思考,反而容易引入错误的设计,造成更多的麻烦。


所以说,“经典太抽象”只是一个事实,只要你能肯花时间认真解读,学下去并不难。


误解二:设计模式太单一,复杂业务场景难落地


现在,对于设计模式,有两个非常有意思的现象

  1. 在理论学习中,几乎所有的开发人员都认为它很重要。
  2. 在工作实践中,绝大部分开发人员在项目中又找不到合适的应用场景。



其实,发生这个冲突的关键点在于:没有搞清楚设计模式解决问题的范围所在。换句话说,设计模式并不是一种全场景的解决方案,它需要考虑适用范围。


比如,在面向对象语言 Java 领域中,如何最大限度发挥面向对象语言的继承与组合的威力?如何解耦程序的相互依赖?设计模式会提供一些解答。


如果说你现在接到的是一个复杂系统的设计任务,比如,如何设计一个秒杀系统?你不仅需要关心业务功能的实现,还要关心不同开发成员间的相互配置、服务器资源等,而此时你的脑海中浮现设计模式中的适配器模式、策略模式、状态模式……对你来说帮助并不那么明显,因为你其实还没有到如此需要细节实现的阶段。


实际上,设计模式的提出就是为了解决限定领域的有限问题。 比如,针对非业务场景的技术框架,如何实现可复用的软件?如何能够为更多的人提高编程效率?像 Spring、Netty、MyBatis、JDK 等大家公认的工具,其实随处可见设计模式的应用,但同时并不是只有设计模式本身。


所以说,你不能把设计模式当作一种通用解决方案来对待,或者认为它就应该解决超出范围的问题,一定要考虑好它的适用范围,否则问题是得不到有效解决的。


误解三:模式既然很好用,那么一切皆模式


好的设计从来不是看用的模式有多少,而是看如何合理利用模式的设计思想,以及如何利用模式解决真实的问题。

所以说,学习设计模式是为了启发我们的思考,而不是“手里握着锤子,满世界找钉子”


如何正确学习设计模式


首先,要摆正心态。


设计模式不是万能灵药,不是银弹,设计模式能解决的问题其实是有限的,你应该始终保持一个平常的心态,正确分析设计模式可以解决和不能解决的问题。


其次,搞清楚设计模式的背景知识


比如,设计模式如何定义?设计模式的历史演进与变化?设计模式有哪些适用的领域?又有哪些不适用的领域?如何结合实践分析和使用?


学习一门知识时,如果总是忽略关联的背景知识,久而久之会养成零碎知识积累的习惯——收藏了很多资料,拆解、吸收却很少。而在学习关联知识时,你会发现,原来的知识会逐渐连接和串联起来,这是一个事半功倍的动作。


再次,努力具备高手独立思考的习惯


互联网时代,不缺资料和方法,缺的是能解决复杂难题的高手。高手之所以成为高手,是因为高手不拘泥于某一知识的高低贵贱,而是保持明智的判断,始终朝着坚定的目标前行。


相关文章
|
4月前
|
设计模式 监控 算法
后端开发中的设计模式:从理论到实践
【8月更文挑战第21天】在软件开发的广阔天地中,设计模式犹如星辰,指引着开发者们走向更加优雅、高效的代码世界。本文将深入浅出地探讨后端开发中常用的几种设计模式,通过实际案例分析它们如何被应用于解决现实世界的问题,并讨论这些模式背后的哲学思考和对未来技术发展的启示。
|
4月前
|
设计模式 算法 开发者
后端开发中的设计模式探索之旅
【8月更文挑战第21天】设计模式是解决常见问题的优雅方案,它们在软件开发中扮演着至关重要的角色。本文将带你走进后端开发的世界,探索设计模式如何影响代码结构、提升可维护性与扩展性,并分享一些实用的设计模式案例。通过深入浅出的方式,我们将一起理解设计模式背后的哲学和它们在日常开发工作中的应用价值。
|
7月前
|
设计模式 缓存
理解并应用设计模式在软件开发中的重要性
【5月更文挑战第20天】设计模式是软件开发中的最佳实践,用于解决常见设计问题,提高代码可读性、可维护性、可扩展性和灵活性。本文介绍了为何需要设计模式(如管理依赖、增强可重用性、设计易扩展系统)以及常见的设计模式:工厂模式(封装对象创建)、单例模式(确保类唯一实例)、观察者模式(事件驱动)和适配器模式(解决接口不兼容)。应用设计模式的关键步骤包括识别问题、选择模式、实现模式及测试优化。设计模式对于提升代码质量和降低系统风险至关重要。
|
7月前
|
设计模式 缓存 算法
谈谈我工作中的23个设计模式
从基础的角度看,设计模式是研究类本身或者类与类之间的协作模式,是进行抽象归纳的一个很好的速成思路。后面阅读设计模式后,为了加深理解,对相关图片进行了描绘和微调。 从技术的角度已经有很多好的总结,本文会换一种角度思考,既然设计模式研究的是类与类的关系,我们作为工作的个体,一些工作中的策略是不是也可以进行类比,可以更好地去思考这些模式?答案是肯定的。
|
7月前
|
设计模式 存储 缓存
设计模式全览:编程艺术的精髓!
设计模式全览:编程艺术的精髓!
53 0
|
设计模式 SQL Java
设计模式的七大原则(设计模式必修课)
设计模式(Design Pattern)是针对于软件设计中反复出现的问题所提出来的一个解决方案,是前人对代码开发经验的总结,它不是语法规定,学好设计模式可以开阔我们的编程思维,让我们编写的程序具备可复用性、可扩展性、可读性、可靠性以及安全性等;
7814 0
|
7月前
|
设计模式 SQL 缓存
设计模式概括认知
设计模式概括认知
46 0
|
设计模式
设计模式系列教程(03) - 设计模式分类及六大原则
设计模式系列教程(03) - 设计模式分类及六大原则
45 0
|
设计模式 算法 前端开发
软件开发常见的一些设计模式,留着供自己研究和面试使用
说到软件开发,就不得不提到设计模式,比如大家基本上都用过什么MVC框架开发各种系统,一些好的设计模式不仅能让软件运行的更为流畅,更能让开发人员的工作效率大大提高。本文就来列举一些常用的设计模式,供大家参考收藏。
140 1
|
设计模式 Java uml
设计模式宏观-系统学习五
武侠中有修炼内功和外功之分;程序界也有,而设计模式就是程序界的内功心法之一;我们在写框架或者工程的时候都要尽可能的遵循设计原则,设计模式则是在不同场景下的具体应用。