设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
22327 人已学习
课程目录
已更新 84 讲 / 共 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 | 在实际的项目开发中,如何避免过度设计?又如何避免设计不足?
开源与项目实战:开源实战 (5讲)
76 | 开源实战一(上):通过剖析Java JDK源码学习灵活应用设计模式
77 | 开源实战一(下):通过剖析Java JDK源码学习灵活应用设计模式
78 | 开源实战二(上):从Unix开源开发学习应对大型复杂项目开发
79 | 开源实战二(中):从Unix开源开发学习应对大型复杂项目开发
80 | 开源实战二(下):从Unix开源开发学习应对大型复杂项目开发
不定期加餐 (3讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
春节特别加餐 | 王争:如何学习《设计模式之美》专栏?
免费
设计模式之美
15
15
1.0x
00:00/00:00
登录|注册

78 | 开源实战二(上):从Unix开源开发学习应对大型复杂项目开发

王争 2020-05-01
软件开发的难度无外乎两点,一是技术难,意思是说,代码量不一定多,但要解决的问题比较难,需要用到一些比较深的技术解决方案或者算法,不是靠“堆人”就能搞定的,比如自动驾驶、图像识别、高性能消息队列等;二是复杂度,意思是说,技术不难,但项目很庞大,业务复杂,代码量多,参与开发的人多,比如物流系统、财务系统等。第一点涉及细分专业的领域知识,跟我们专栏要讲的设计、编码无关,所以我们重点来讲第二点,如何应对软件开发的复杂度。
简单的“hello world”程序,谁都能写得出来。几千行的代码谁都能维护得了。但是,当代码超过几万行、十几万,甚至几十万行、上百万行的时候,软件的复杂度就会呈指数级增长。这种情况下,我们不仅仅要求程序运行得了,运行得正确,还要求代码看得懂、维护得了。实际上,复杂度不仅仅体现在代码本身,还体现在协作研发上,如何管理庞大的团队,来进行有条不紊地协作开发,也是一个很复杂的难题。
如何应对复杂软件开发?Unix 开源项目就是一个值得学习的例子。
Unix 从 1969 年诞生,一直演进至今,代码量有几百万行,如此庞大的项目开发,能够如此完美的协作开发,并且长期维护,保持足够的代码质量,这里面有很多成功的经验可以借鉴。所以,接下来,我们就以 Unix 开源项目的开发为引子,分三节课的时间,通过下面三个话题,详细地讲讲应对复杂软件开发的方法论。希望这些经验能为你所用,在今后面对复杂项目开发的时候,能让你有条不紊、有章可循地从容应对。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(18)

  • Jxin
    1.不用哪些,只要一个,就是合理的分层。

    2.大型软件的持续开发,。人多,代码量大,时间长会有这三个问题。


    3.人多:人一多什么鸟都有,在快节奏下,你很难去保证所有人的所有代码质量。即便你有code review,但质量是要对业务做让步的,而这是合理的。那么这时候去要求每个人的,编码规范,抽象封装能力,就非常的难。所以这些能力对软件质量很重要,但你抓不了也是白搭。反观分层,它其实是限定了一块业务逻辑,实现代码的基本拆分和归类,定义了一个基本的规范。任何人都可以顺着这个规范去阅读他人的代码。实现了最基本的复杂性隔离。可执行可落地,试用期基本就可以灌输成功。

    4.代码量大:对于代码量大的项目,要找到目标功能,是很痛苦的。而分层在这时候就具备类似索引的功能。哪怕项目没注释,只要它按着分层写,你就可以顺着 业务 功能 细节这样的线去摸到目标功能,无需从入口开始读代码。

    5.时间长:软件在时间线上是动态的,当下的业务边界很可能因时间的推移而被变革,需要重组模块的数据范围和业务边界。好的分层可以让你更快的重组模块,解决当前模块划分不合理的问题。具体可以看下ddd的分层。它可以让你在重组模块时,只需花一两个小时,剪切粘帖整块聚合的业务代码,并调整一些基础功能的实现,便能实现模块重组。而不需长达数个月的风险评估,代码调整,测试覆盖。
    2020-05-03
    4
  • 下雨天
    分层和模块化,基于接口通讯,这两点最重要!
    这个相当于整个架构搭起来了,每个模块怎么划分怎么交流定好了,其他扩展行,可读性,抽象都可以细化到模块中实施。
    2020-05-05
    3
  • Frank
    我觉得在大型项目开发中,单一职责和最小知识原则也是发挥很大的作用,从编码角度来看,类,模块都遵守单一和最小知识原则,这样的话内聚性高,耦合少,每个类和模块可能都不会太复杂,可读性,可测试性也就不会太差。从一个系统的生命周期来看,单一职责体现为产品,开发,测试,运维。各个角色的人各司其职,耦合不会太多,能有效的提高效率。会想起以前在某家传统公司,需求沟通、设计、编码、测试、维护几乎要自己一个人干,有时候觉得太累。
    2020-05-01
    2
  • 辣么大
    五一快乐!
    我觉得抽象封装和分层模块化最能发挥作用。最近在看ROS机器人操作系统,是开源一个中间件系统,思想是通过封装,抽象,使得不懂硬件的程序员可以对机器人进行编程。里面所有的可执行程序,都可以叫做一个node(节点),机器人可以组装的(移动底盘,机器臂等)这个是模块化,机械臂控制使用moveit运动学控制规划模块,底座导航使用导航功能模块,这个算是模块化。机器的各个部分,都使用命名空间的方式访问,和争哥将的linux系统结构的方式差不多。
    2020-05-01
    2
  • jaryoung
    个人觉得是:高内聚、松耦合,高内聚说明合适的人都在一起了,松耦合说明不合适的人的都隔离起来。
    2020-05-02
    1
  • + +
    在大型软件开发中 模块化和分层 分别从横行和纵向 两种相互垂直的方向来划分软件结构
    2020-05-01
    1
  • will
    好的设计会满足抽象封装模块化等各种特性。
    2020-05-07
  • 漫游者
    我觉得还有一点是需求管理吧,好像跟设计思想和原则没有关系~~。我们写代码除了实现功能,更重要的是面向未来做扩展。如果需求是可预期的,其实更容易让我们去运用老师说的设计思想原则模式等等。
    2020-05-06
  • 不能忍的地精
    分层和模块化,有效的将软件的复杂性限制在了层里面和模块里面
    2020-05-06
  • J
    封装与抽象、分层与模块化、基于接口通信,我觉得是最重要的三个设计原则。

    封装与抽象是从使用者的角度来考虑系统该如何设计。
    分层与模块化则是在系统建设者之间划分好界限和职责。
    基于接口通信构建了内外之间最合适的交互方式。
    2020-05-05
  • 守拙
    课堂讨论:

        在大型项目开发中, 分层与模块化最能发挥作用.

        分层与模块化思想搭建项目骨架, 层间通信或模块间通信可以应用基于接口而非实现的原则通信, 提高了扩展性.

        而分层与模块化自然而然的实现了封装与抽象的原则.
        
        而某一层或某一模块的具体实现可以参考KISS原则, 最小惊奇原则等进行设计.
    2020-05-05
  • L🚲🐱
    单一职责原则和为扩展而设计以及高内聚低耦合
    2020-05-05
  • javaadu
    年前做的一个项目,是一个能力编排引擎,这是我实际参与的第一个具备良好设计的软件项目,满足了:抽象和封装、模块化和分层结构、基于接口而非实现编程等设计原则,在这个项目中我才真正获得了对这些设计原则的理解。这个经历说明—我应该尽量去高水平高素质的团队,才有机会遇到高水平的项目和代码
    2020-05-05
  • 忆水寒
    分层、模块化、接口编程 最实用的技巧。
    2020-05-04
  • 三木子
    现在微服务很火,服务切分按照模块来的。
    2020-05-04
  • Geek_54edc1
    最小惊奇原则吧,实际上大型业务系统的架构都大同小异,有些特定的程式,但是实际编码过程中,对于开发规范的遵守,就很重要了,这个直接影响代码可读性,如果不好好遵守,各行其是,“破窗效应”就会显现,导致代码越来越难维护,严重打击开发团队的信心~~~
    2020-05-01
  • Heaven
    这一篇教导的是一些实际开发中的经验,如果没有接触过实际开发的同学,可能会觉得对上面原则的取舍比较困难,这就需要在不断实战中积累
    顺便一提今天的问题,在现在的开发中,最重要的必然是封装
    操作系统将网络连接封装为了Socket函数,而浏览器和各种高级语言会对于Socket再进一次的封装,方便我们的开发,
    并且如果没有封装,现在可能从事编程的人员需要各个从底层硬件开始了解,互联网也不会发展如此的快了
    2020-05-01
  • 小晏子
    个人认为有效降低复杂性的原则是封装抽象和分层模块化,封装抽象能够使一些通用功能服用,降低复杂性,分层模块化可以方便多人协调开发,还可以让开发人员专注于某些层级模块的代码实现。
    2020-05-01
收起评论
18
返回
顶部