设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
18612 人已学习
课程目录
已更新 30 讲 / 共 100 讲
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 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (1讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册

26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?

王争 2020-01-01
在上一节课中,我们对计数器框架做了需求分析和粗略的模块划分。今天这节课,我们利用面向对象设计、实现方法,并结合之前学过的设计思想、设计原则来看一下,如何编写灵活、可扩展的、高质量的代码实现。
话不多说,现在就让我们正式开始今天的学习吧!

小步快跑、逐步迭代

在上一节课中,我们将整个框架分为数据采集、存储、聚合统计、显示这四个模块。除此之外,关于统计触发方式(主动推送、被动触发统计)、统计时间区间(统计哪一个时间段内的数据)、统计时间间隔(对于主动推送方法,多久统计推送一次)我们也做了简单的设计。这里我就不重新描述了,你可以打开上一节课回顾一下。
虽然上一节课的最小原型为我们奠定了迭代开发的基础,但离我们最终期望的框架的样子还有很大的距离。我自己在写这篇文章的时候,试图去实现上面罗列的所有功能需求,希望写出一个完美的框架,发现这是件挺烧脑的事情,在写代码的过程中,一直有种“脑子不够使”的感觉。我这个有十多年工作经验的人尚且如此,对于没有太多经验的开发者来说,想一下子把所有需求都实现出来,更是一件非常有挑战的事情。一旦无法顺利完成,你可能就会有很强的挫败感,就会陷入自我否定的情绪中。
不过,即便你有能力将所有需求都实现,可能也要花费很大的设计精力和开发时间,迟迟没有产出,你的 leader 会因此产生很强的不可控感。对于现在的互联网项目来说,小步快跑、逐步迭代是一种更好的开发模式。所以,我们应该分多个版本逐步完善这个框架。第一个版本可以先实现一些基本功能,对于更高级、更复杂的功能,以及非功能性需求不做过高的要求,在后续的 v2.0、v3.0……版本中继续迭代优化。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(31)

  • geek
    新年快乐 一起学习 一起提高 2020
    2020-01-01
    16
  • 辣么大
    想了三点,希望和小伙伴们讨论一下:
    1、RequestInfo save 一次写入一条。是否需要考虑通过设置参数,例如一次写入1000或10000条?好处不用频繁的与数据库建立连接。
    2、聚合统计Aggregator是否可以考虑不写代码实现统计的逻辑,而是使用一条SQL查询实现同样的功能?
    3、EmailReporter startDailyReport 没指定明确的统计起止时间。设置统计指定区间的request info,例如08:00~次日08:00,然后发邮件。
    2020-01-01
    2
    7
  • Jxin
    沙发!
    1.栏主新年快乐。零点发帖,啧啧啧。
    2.给出github地址吧,我们来提pr,一个学习用demo大家合力下就当练手,没必要自己死磕全实现哈。
    3.关于邮件和控制台两个接入层。实现代码重了。可以把定时统计下沉到下一层来实现,然后两个接入层共用这个实现。然后收集的统计数据的类型应该可以提供差异化配置的api。在消费统计数据的消息时,做差异化分发,实现各接入层仅看到自己想看的数据。

    4.spring1.x~3.x,兼容老版本做得挺好。springboot在自动装配的实现上下足了功夫(插件化,易插拔)。netty的实现也挺挺讲究,还能顺带学网络相关知识。以上其实都运用一系列设计原则。在没看栏主专栏前,我是啃这些学的场景。
    2020-01-01
    4
    6
  • Eden Ma
    2020新年快乐 早上醒来第一件事就是听卖🍑者和看争哥的更新
    2020-01-01
    4
  • 卫江
    上面的代码设计与实现,我认为有两个重点是需要改进的:
    1. 不同的统计规则,通过抽象统计规则抽象类,每一个具体的统计(最大时间,平均时间)单独实现,同时在 Aggregator 内中通过 List等容器保存所有的统计规则实现类,提供注册函数来动态添加新的统计规则,使得Aggregator否则开闭原则,各个统计规则也符合单一责任原则。
    2. 显示方式很明显是一个变化点,需要抽象封装,抽象出 显示接口,在汇报类中通过依赖注入的方式来使用具体的显示类,这样一来,reporter类更加责任单一,我们也可以通过扩展新的显示类来扩展功能,符合开闭原则,每一个显示实现类更加否则单一责任。
    2020-01-02
    2
    2
  • 啦啦啦
    新年快乐
    2020-01-01
    2
  • Murrre
    https://github.com/murreIsCoding/learning_geek/tree/master/src/main/java/design_pattern/demo2/performance_monitoring
    敲了一下,主要是实现了redis存储部分逻辑,redis命令不是很熟,可能有更好的方案
    2020-01-02
    1
  • 哈喽沃德
    什么时候开始讲设计模式呢
    2020-01-02
    1
  • Young!
    我觉得在使用方面需要优化,1,建议可以将使用哪个数据库存储方式,时间范围,使用邮箱还是命令行作为输出做成类似 spring 的可配置项,2,减少启动代码,最好使用一行或者注解就可以起到拦截请求并统计输出的作用。
    2020-01-01
    1
  • Frank
    打卡,今天又进步一点点,利用元旦的时间,将上一篇和这一篇的内容过了一遍,参照文章的思路使用代码简单实现了一遍,加深了理解。
    2020-01-01
    1
  • Jeff.Smile
    争哥这套课程确实呕心沥血,哈哈
    2020-01-01
    1
  • Monday
    RequestInfo.timestamp属性是接口响应的开始时间戳吗?如果是的话,说明我被Demo中的10234,11234这类数据给误导了
    2020-01-01
    1
  • Geek_3b1096
    喜欢一小步一小步改进过程
    2020-01-01
    1
  • 守拙
    课堂讨论Answer:



    对于今天的设计与代码实现,你有没有发现哪些不合理的地方?有哪些可以继续优化的地方呢?或者留言说说你的设计方案。



    Aggregator类的问题较大.它不符合开闭原则.



    说一个你觉得不错的开源框架或者项目,聊聊你为什么觉得它不错?

    https://github.com/square/retrofit

    反射与动态代理的典范.
    2020-01-02
  • 猫头鹰爱拿铁
    可否提供下类图,整体上看着更方便。

    作者回复: 自己画画?

    2020-01-02
  • Geek_54edc1
    1、今天的代码没有做容错处理;代码的效率问题也没有优化,比如争哥在文章里所提到得一次取太长数据导致内存占用过高,还有代码中收集和存储采用同步方式,也会影响到性能
    2020-01-02
  • whistleman
    打卡,加油,2020坚持!
    2020-01-02
  • AaronYu
    把老师的代码做了一个整理,试着运行了一下。
    小伙伴们感兴趣的可以看一下:https://github.com/Aaronyu29/DesignPattern/tree/master/src/u026
    2020-01-02
  • 堵车
    要写出优美的代码,首先要有一颗对丑陋代码厌恶的心
    2020-01-02
  • 睡觉💤
    1.简单用过prometheus 对比 prometheus提出一个小问题
    拉取数据的时候需要分项目 用户需要观看一个项目的中的多个数据项,所以拉取数据接口确实一个分组参数
    2.目前没有看过源码,不好做出评价。如果非要说的话golang的标准库的设计是非常优秀的。哈哈哈这是一句废话
    2020-01-02
收起评论
31
返回
顶部