设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
22230 人已学习
课程目录
已更新 82 讲 / 共 102 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (12讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
25 | 实战二(上):针对非业务的通用框架开发,如何做需求分析和设计?
26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (11讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
29 | 理论三:什么是代码的可测试性?如何写出可测试性好的代码?
30 | 理论四:如何通过封装、抽象、模块化、中间层等解耦代码?
31 | 理论五:让你最快速地改善代码质量的20条编程规范(上)
32 | 理论五:让你最快速地改善代码质量的20条编程规范(中)
33 | 理论五:让你最快速地改善代码质量的20条编程规范(下)
34 | 实战一(上):通过一段ID生成器代码,学习如何发现代码质量问题
35 | 实战一(下):手把手带你将ID生成器代码从“能用”重构为“好用”
36 | 实战二(上):程序出错该返回啥?NULL、异常、错误码、空对象?
37 | 实战二(下):重构ID生成器项目中各函数的异常处理代码
设计原则与思想:总结课 (3讲)
38 | 总结回顾面向对象、设计原则、编程规范、重构技巧等知识点
免费
39 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(上)
40 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(下)
设计模式与范式:创建型 (7讲)
41 | 单例模式(上):为什么说支持懒加载的双重检测不比饿汉式更优?
42 | 单例模式(中):我为什么不推荐使用单例模式?又有何替代方案?
43 | 单例模式(下):如何设计实现一个集群环境下的分布式单例模式?
44 | 工厂模式(上):我为什么说没事不要随便用工厂模式创建对象?
45 | 工厂模式(下):如何设计实现一个Dependency Injection框架?
46 | 建造者模式:详解构造函数、set方法、建造者模式三种对象创建方式
47 | 原型模式:如何最快速地clone一个HashMap散列表?
设计模式与范式:结构型 (8讲)
48 | 代理模式:代理在RPC、缓存、监控等场景中的应用
49 | 桥接模式:如何实现支持不同类型和渠道的消息推送系统?
50 | 装饰器模式:通过剖析Java IO类库源码学习装饰器模式
51 | 适配器模式:代理、适配器、桥接、装饰,这四个模式有何区别?
52 | 门面模式:如何设计合理的接口粒度以兼顾接口的易用性和通用性?
53 | 组合模式:如何设计实现支持递归遍历的文件系统目录树结构?
54 | 享元模式(上):如何利用享元模式优化文本编辑器的内存占用?
55 | 享元模式(下):剖析享元模式在Java Integer、String中的应用
设计模式与范式:行为型 (18讲)
56 | 观察者模式(上):详解各种应用场景下观察者模式的不同实现方式
57 | 观察者模式(下):如何实现一个异步非阻塞的EventBus框架?
58 | 模板模式(上):剖析模板模式在JDK、Servlet、JUnit等中的应用
59 | 模板模式(下):模板模式与Callback回调函数有何区别和联系?
60 | 策略模式(上):如何避免冗长的if-else/switch分支判断代码?
61 | 策略模式(下):如何实现一个支持给不同大小文件排序的小程序?
62 | 职责链模式(上):如何实现可灵活扩展算法的敏感信息过滤框架?
63 | 职责链模式(下):框架中常用的过滤器、拦截器是如何实现的?
64 | 状态模式:游戏、工作流引擎中常用的状态机是如何实现的?
65 | 迭代器模式(上):相比直接遍历集合数据,使用迭代器有哪些优势?
66 | 迭代器模式(中):遍历集合的同时,为什么不能增删集合元素?
67 | 迭代器模式(下):如何设计实现一个支持“快照”功能的iterator?
68 | 访问者模式(上):手把手带你还原访问者模式诞生的思维过程
69 | 访问者模式(下):为什么支持双分派的语言不需要访问者模式?
70 | 备忘录模式:对于大对象的备份和恢复,如何优化内存和时间的消耗?
71 | 命令模式:如何利用命令模式实现一个手游后端架构?
72 | 解释器模式:如何设计实现一个自定义接口告警规则功能?
73 | 中介模式:什么时候用中介模式?什么时候用观察者模式?
设计模式与范式:总结课 (2讲)
74 | 总结回顾23种经典设计模式的原理、背后的思想、应用场景等
75 | 在实际的项目开发中,如何避免过度设计?又如何避免设计不足?
开源与项目实战:开源实战 (3讲)
76 | 开源实战一(上):通过剖析Java JDK源码学习灵活应用设计模式
77 | 开源实战一(下):通过剖析Java JDK源码学习灵活应用设计模式
78 | 开源实战二(上):从Unix开源开发学习应对大型复杂项目开发
不定期加餐 (3讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
春节特别加餐 | 王争:如何学习《设计模式之美》专栏?
免费
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

75 | 在实际的项目开发中,如何避免过度设计?又如何避免设计不足?

王争 2020-04-24
设计模式的理论部分已经全部学习完了。现在,你可能已经蠢蠢欲动,想要赶紧实践一把,把这些理论应用到自己的项目中。不过,这里我要给你提个醒了,千万别手里拿着锤子就看什么都是钉子啊。
在我过往的项目经历中,经常遇到两种同事。
一种同事会过度设计。在开始编写代码之前,他会花很长时间做代码设计,在开发过程中应用各种设计模式,美其名曰未雨绸缪,希望代码更加灵活,为未来的扩展打好基础,实则过度设计,未来的需求并不一定会实现,实际上是增加了代码的复杂度,以后的所有开发都要在这套复杂的设计基础之上来完成。
除此之外,还有一种是设计不足。怎么简单怎么来,写出来的代码能跑就可以,顶多算是 demo,看似在实践 KISS、YAGNI 原则,实则忽略了设计环节,代码毫无扩展性、灵活性可言,添加、修改一个很小的功能就要改动很多代码。
所以,今天我想和你聊一下,在实际的项目开发中,如何避免过度设计,以及如何避免设计不足。话不多说,让我们正式开始今天的内容吧!

设计的初衷是提高代码质量

创业时,我们经常会讲到一个词:初心。这词说的其实就是,你到底是为什么干这件事。不管走多远、产品经过多少迭代、转变多少次方向,“初心”一般都不会随便改。当我们在为产品该不该转型、该不该做某个功能而拿捏不定的时候,想想它符不符合我们创业的初心,有时候就自然有答案了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(21)

  • Jackey
    滥用设计模式真的是不如不用
    2020-04-24
    8
  • 黄林晴
    打卡
    持续重构真的很重要
    我现在看自己去年的代码都看不下去
    相信明年的我看今年重构后的代码也看不下去
    2020-04-24
    4
  • Jxin
    1.回答这两个问题。在该有的知识都具备的情况下。其实是在问,你的初心是什么。

    2.如果你的初心是“保证项目持续迭代的效率”,或者说保证项目架构的持续优异。那么快速的先落地需求+持续重构会是主色调。这种模式下,落地需求不会有太多的过度设计,设计不足也能在持续重构中被摆正。但是,这非个人的事情,需要团队甚至整个公司的共同支持与认可。

    3.如果你的初心是“写出高质量代码”。那么过度设计在所难免。可是,这问题很大吗?实际工作中,不会有人有时间一直去揣摩你的代码。而真要阅读你的代码,一般也是能看懂的。所以对团队的影响其实还是比较有限的,但对自己的认知和成长是有好处的。这么玩并不为过,重要的是保持谦逊,因为这个时候写的代码更多是实践知识点,缺少平衡架构合理和需求场景时的抉择,硬拿经典用例或伪需求来强调自己牛逼就有点令人生厌了。
    2020-04-24
    2
  • cugphoenix
    争哥的课真的是满满干货,精髓就在于这对于设计思想的讲解,非常接地气。
    2020-04-24
    2
  • Liam
    往往只有过度设计之后才能学会适度设计
    2020-04-26
    1
  • 守拙
    在日常工作中, 设计不足是经常出现的事情. 毕竟不是每个人都学过设计模式, 理解设计模式, 能正确的应用设计模式. 不知道你们怎么样, 我相处过的同事, 大多不懂或对设计模式一知半解. 包括我自己, 没系统学习本专栏前对设计模式的理解是非常浅薄的.

    我认为理解设计思想, 学习设计模式任重道远. 试想, 你的团队协作成员全部具有设计意识, 不仅写出的代码健壮性强, 可读性, 可维护性好, 日常沟通效率也大大提升(加班还是要加班的, 效率高了加班摸鱼或者看书总比写业务强吧).

    至于过度设计的问题, 新手难免会犯. 就像学习穿衣搭配一样, 不花个万八千买衣服扔衣服, 就永远学不会. 个人对于过度设计的看法就是多写多总结并持续重构. 过度设计并不是一件不可饶恕的事情, 只要有设计意识, 总有一天新手也会成长为高手, 过度设计的问题也就自然解决了.
    2020-04-24
    1
  • 小晏子
    避免过度设计和设计不足的经验基本上文章覆盖的很全了,如果能做到文中提到的点基本上就可以避免。另外个人感觉可以把设计方案放到组内讨论,看看别人的反应,一般过渡地太复杂的设计都会有人反对。
    2020-04-24
    1
  • leezer
    主要核心还是知道为啥要用设计模式
    2020-04-24
    1
  • mooneal
    专栏看下来的理解:
    要写高质量的代码,首先要有辨别代码坏味道的能力;其次要有写好代码的意识以及丰富的理论知识;然后要问自己为什么要重构这一块的代码,解决了哪些现有的问题,而不是未知的问题;最后开始重构出高质量的代码吧。
    2020-04-28
  • 个人总结:
    架构分为三个阶段,需求分析,根据用户故事,分析用户的核心需求,产出需求文档,划分需求边界
    概要设计,根据需求文档和边界产出大概的系统模型,模块交互关系
    详细设计,根据模块类型定义数据结构,表结构,确定变与不变,进而考虑是否需要设计模式来解耦
    个人认为遵循这个方式去思考,可以一定程度上避免过渡设计/设计不足,然后实际开发中,需求变更难以预料,不容易确定变与不变,这时最好不要使用设计模式
    2020-04-27
  • 辣么大
    如何避免过度设计?如何避免设计不足?
    过度设计属于懂理论,但实践经验不足。设计不足,是缺乏相关的理论知识,考虑的比较窄。中国人讲究个中庸,不能极端,“平衡”的感觉往往很难把握。自己写代码的时候,最近总想着解耦,函数层面,类的层面,功能层面,模块层面。这些需要经验和抽象能力,经验不足的时候多看看开源社区好的项目代码吧,想想他们怎么设计的。
    2020-04-25
  • 乾坤瞬间
    无招胜有招的前提是先要把招数给学个心中有数,前期就是要以设计为真理,然后慢慢去除华丽的外衣,当个朴素的农民,哈哈
    2020-04-24
  • 荀麒睿
    工作中有个同事,刚学习了设计模式,然后就在代码中使用了,结果初学初用,又没有持续重构,导致别人在这个基础上做修改,变得异常的复杂,然后又因为项目多,别人也不会有时间再去重构这些代码,最后就是所有要修改的人只能照着这个复杂的模式继续操作。设计模式固然重要,但是有些时候滥用还真的是不如不用的好。
    2020-04-24
  • 小文同学
    学习设计模式,距离应用到自己的代码还有一些距离。我个人会倾向去读开源代码,看看他们是用设计模式去解决什么问题。
    这样即对理解源码有很大的帮助,同时也能学习设计模式的应用场景。

    至于应用场景,我觉得可以先冲重构开始做起,观察一段让人不舒服的业务代码,考虑代码是否可以重构,重构用那种模式更加合理等等。

    我期望的境界,是对设计模式有深入理解时,清楚地理解每种设计模式的边界,能够轻松地驾驭业务或框架的实现。
    2020-04-24
  • 子夜
    有设计的意识,不一定要做。
    项目很大,参与者多,偏底层,最好队各个功能模块提前设计。
    一般项目开发还是以需求为主,先做出来,然后不断重构。
    2020-04-24
  • 三木子
    学习设计模式如喝茶。一杯好茶需要时间浸泡,学习设计模式也要工作经验浸泡。茶水味道需要细品。不带味觉去喝,犹如喝白开水。设计模式不带思考去品,犹如喝了一碗没有补到身体补品!
    2020-04-24
  • zs阿帅
    现在感觉就是学完了所有招式,蠢蠢欲动,写个代码就想能用什么设计模式
    2020-04-24
  • Heaven
    在实际开发中,我认为 设计合适>过度设计>不进行设计,往往不进行设计的工程师,要么是没有了解过对应的知识,要么是对知识的不熟悉掌握,我个人也经常犯过度设计的毛病,但是我个人的观点是,如果学完了东西,尽可能的去尝试使用它,因为不使用它,那么可能一直就没有机会去使用,或者真正合适用的场景,也想不起来,不要畏惧自己的过度设计,因为没有过度设计的错误的铺垫,可能就永远没法设计出恰到好处的代码,没有人能一蹴而就,学习这条道路上都是踩着坑过来的
    2020-04-24
  • mghio
    设计模式还是得看具体业务场景,不能硬套
    2020-04-24
  • 忆水寒
    前提是把握需求才能做好功能分析,然后才能划分功能。最后才是基于功能进行设计开发。
    2020-04-24
收起评论
21
返回
顶部