设计模式之美
王争
前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
下载
客户端
返回
顶部