软件设计之美
郑晔
推文科技技术VP,前火币网首席架构师
立即订阅
2570 人已学习
课程目录
已更新 7 讲 / 共 34 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 软件设计,应对需求规模的“算法”
免费
课前必读 (3讲)
01 | 软件设计到底是什么?
02 | 分离关注点:软件设计至关重要的第一步
03 | 可测试性: 一个影响软件设计的重要因素
了解一个软件的设计 (3讲)
04 | 三步走:如何了解一个软件的设计?
05 | Spring DI容器:如何分析一个软件的模型?
06 | Ruby on Rails:如何分析一个软件的接口?
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

04 | 三步走:如何了解一个软件的设计?

郑晔 2020-06-01
你好!我是郑晔。
经过了前面几讲的铺垫,我们已经对软件设计是什么,以及要考虑哪些因素有了一个初步的了解。热身之后,就该开启正式的旅程了。
作为一个程序员,我们在职业生涯中免不了要接手新项目,承担维护该项目的职责。如果一个新项目摆在面前,你会怎么去研究它呢?
很多人的第一反应就是去看源代码。但是,一头扎入代码中,很快你就会迷失其中,最初那股子探索精神,也会逐渐被迷茫所代替。回想一下,有多少次你满怀希望地打开一个开源项目,结果多半都是坚持不了多久就放弃了。你有没有想过,问题出在哪里呢?
你的迷茫在于缺少对这个软件整体的了解,这就如同不带地图指南针闯入密林一般,迷路只是早晚的事。所以,虽然阅读源码是必经的一步,却不应该是你的第一步。我们应该先从了解软件的设计开始。那我们该如何了解一个软件的设计呢?

模型、接口和实现

了解一个软件的设计可以从三个部分着手:模型、接口和实现。这三者的关系就好比你去看代码,你会先去看有哪些类以及它们之间的关系,这就是看模型;然后你会打开一个具体的类,看它提供了哪些方法,这就相当于看接口;最后,你再来打开一个具体的方法,去看它的代码是怎么写的,这就是看实现。
好,接下来,我们具体地分析一下每一个部分。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件设计之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • Kǎfκã²⁰²⁰
    模型,通常包含两类要素,一是基本元素,二是这些元素之间的关系。比如常见的CRM,基本元素就包括项目、客户、合同和回款,相互之间的主要关系通常是客户报备,进入立项环节(评估投入产出),再签约,最后进入回款环节。这是基本模型。

    这个模型(系统)的接口,就是要为BD提供从客户报备到签约、回款的整个流程管理。

    实现就是要考虑如何用消息在这些模块之间传递数据,状态控制、数据查重锁定等等。

    作者回复: 赞,这个思路很清晰!

    2020-06-01
    1
    8
  • Geek_3b1096
    喜欢老师只能记住一件事总结风格

    作者回复: 能记住就好。

    2020-06-02
    3
  • 一步
    当使用一个新的 库或者框架的时候 首先看的是 接口,看对外提供的功能的是否满足自己的要求,然后才是 具体的实现。 对于模型 想学习开源软件的架构的时候在去关注的
    2020-06-01
    3
  • 闲不住的令狐冲
    上周月度回顾会,团队成员提出一个改进项,希望能在软件设计方面给他们进行一些培训。一直苦于不能系统给大家讲解。老师的这个系列简直就是及时雨,特别是这篇三步走,让我在后续准备培训分享的课程里面一下找到了方向。

    作者回复: 很高兴能配合上你的工作。你可以试着讲一下,有不清楚的地方,我们再交流。

    2020-06-02
    2
  • 苦行僧
    看rocketmq的文档,可以先从https://github.com/apache/rocketmq/blob/master/docs/cn/concept.md了解模型开始

    作者回复: 很好的补充!

    2020-06-02
    2
  • FelixFly
    这个分析思路比较好,好多一上来就深入源码细节(实现)容易懵,特别是集成关系比较重的时候,最后都不知道调用到哪地方去了,这样就需要单步跟踪才能了解其脉络。若是先分析了类的层次关系,有个一定的理解,后面的调用脉络就有一定的清晰认识。模型这部分比较难理解,要想到作者为什么会这样定义模型,这样的设计用途是什么,可能刚开始不了解,到实现部分有种豁然开朗的感觉。

    作者回复: 有了地图,才不迷路。

    2020-06-01
    2
  • escray
    看了文章,知道自己以前为什么读不懂源码了,因为我每次都是从“实现”入手,想要自顶向上的去了解整个软件的架构,也许这条路也能走通,但是难度太大。

    之前看过《代码阅读方法与实践》(和大多数书一样没能看完),这本书其实就是从细节开始讲起的,书是好书,但是我的打开方式似乎有点问题。

    进程管理的模型包括调度算法,这个稍微有一点不好理解,我之前以为模型都是一些比较“实”的东西。不过如果从模型是“名词” / 概念,接口是“动词” / 命令,实现是动作 / 技术细节这个角度就更清楚一些。

    翻回到专栏的第一篇,老师举例说在交易系统中,有交易原语:下单、成交和撤单,交易动作:冻结、解冻、出金、入金,当时解释说这是模型上的分层。那么我的问题是,这些原语和动作都当做模型来看待么?

    如果让我来分析,那么交易系统的模型可能是:用户、商品、订单、支付、物流;接口是:下单、成交、撤单……

    看到 @Kǎfκã²⁰²⁰ 的留言,他是把“回款”也放到模型里面了。

    似乎是因为老师抽象的层次更高一点,期待下一篇关于模型的讲解。
    2020-06-01
    1
    2
  • Jxin
    1.模型:圈定了数据,明确了边界。在我的数据范围内的业务才是我的业务。模型是业务的抽象定义。
    2.接口:定义了功能,明确了提供什么服务和这个服务的规格。接口是业务的功能口径。
    3.实现:选择技术,明确了功能的性能,满足接口的规格,实现业务的逻辑。实现与业务无关,只考虑接口规格和技术选型。


    以上个人理解。课后题有点广。没办法随手解答。得有时间翻个项目才好说。

    作者回复: 这个课后思考题就是让大家有一个重新思考的过程。

    2020-06-01
    2
  • 三生
    分析框架的流程应当从子模型往上建模,
    若从mvc入手,开始分析其内部的子模型是怎么实现,感觉虽然明显看到顶层模型的交互但是会很含糊。
    认为应当自底向上的进行分析,从框架运行的流程(生命周期)进行模型分析再上升为组件模型,最后总结mvc模型/其他模型,这种分析的方式,虽然相反,但是感觉更容易懂
    2020-06-01
    1
  • 业余爱好者
    使用一个软件,就是通过其接口进行的。接口分为api和ui。要想正确使用一个东西,就要知道一点内部的原理。模型是对内部原理的简化,可以让人快速上手。如果想玩一些高级的玩法,或者想要改造软件,就少不了研究实现了。

    接口和模型组合起来,就相当于一个“ADT”。
    2020-06-01
    1
  • 阳仔
    理解软件开发中的设计可以通过三步走套路:
    模型-接口-实现,
    这个也就是了解软件设计的“模型”。
    模型其实是一个软件设计中的抽象,通过与其它软件设计中的进行对比学习,理解它们的异同,突出自身的核心抽象结构;
    接口是软件交互的入口,是一个软件系统的能力提现,它是一种规范,它与模型共同组成了软件系统的稳定性因素;
    实现是软件设计中对模型和接口的具体的逻辑实现,这个很好理解

    有了这个套路,学习软件设计就有了章法,不会盲目的陷入到软件开发的代码中

    作者回复: 希望这个结构对你理解软件设计有帮助。

    2020-06-01
    1
  • ☆淡蓝水岸☆
    例如在C++的一个小系统中,模型可以理解为定义的类么?接口类似于类里面的函数,接口类似于函数的调用?
    2020-06-04
收起评论
12
返回
顶部