软件设计之美
郑晔
推文科技技术VP,前火币网首席架构师
立即订阅
3268 人已学习
课程目录
已更新 27 讲 / 共 36 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 软件设计,应对需求规模的“算法”
免费
课前必读 (3讲)
01 | 软件设计到底是什么?
02 | 分离关注点:软件设计至关重要的第一步
03 | 可测试性: 一个影响软件设计的重要因素
了解一个软件的设计 (4讲)
04 | 三步走:如何了解一个软件的设计?
05 | Spring DI容器:如何分析一个软件的模型?
06 | Ruby on Rails:如何分析一个软件的接口?
07 | Kafka:如何分析一个软件的实现?
设计一个软件—程序设计语言 (5讲)
08 | 语言的模型:如何打破单一语言局限,让设计更好地落地?
09 | 语言的接口:语法和程序库,软件设计的发力点
10 | 语言的实现:运行时,软件设计的地基
11 | DSL:你也可以设计一门自己的语言
加餐 | 再八卦几门语言!
设计一个软件—编程范式 (9讲)
12 | 编程范式:明明写的是Java,为什么被人说成了C代码?
13 | 结构化编程:为什么做设计时仅有结构化编程是不够的?
14 | 面向对象之封装:怎样的封装才算是高内聚?
15 | 面向对象之继承:继承是代码复用的合理方式吗?
16 | 面向对象之多态:为什么“稀疏平常”的多态,是软件设计的大杀器?
17 | 函数式编程:不用函数式编程语言,怎么写函数式的程序?
18 | 函数式编程之组合性:函数式编程为什么如此吸引人?
19 | 函数式编程之不变性:怎样保证我的代码不会被别人破坏?
加餐 | 函数式编程拾遗
设计一个软件—设计原则与模式 (5讲)
20 | 单一职责原则:你的模块到底为谁负责?
21 | 开放封闭原则:不改代码怎么写新功能?
22 | Liskov替换原则:用了继承,子类就设计对了吗?
23 | 接口隔离原则:接口里的方法,你都用得到吗?
24 | 依赖倒置原则:高层代码和底层代码,到底谁该依赖谁?
软件设计之美
15
15
1.0x
00:00/00:00
登录|注册

06 | Ruby on Rails:如何分析一个软件的接口?

郑晔 2020-06-05
你好!我是郑晔。
在上一讲中,我以 Spring 的 DI 容器为例,给你讲解了如何理解一个项目的模型。在模型之后,下一步就该是接口了。
在任何一个项目中,接口的数量都不是一个小数目。仅仅一个普通的程序库,里面的接口少则几十个,多则成百上千。难道我们理解接口,就是要一个一个地读这些接口吗?
显然,你不太可能把所有的接口细节都记住。我写 Java 程序差不多 20 年了,但很多 JDK 里的类我都不了解。甚至有时候,还没有等我去了解这个类,它就过时了。
那么,如何才能从纷繁复杂的接口中,披荆斩棘而出呢?我给你个方法:找主线,看风格
找主线的意思是,你需要找到一条功能主线,建立起对这个项目结构性的认知,而不是一上来就把精力放在每一个接口的细节上。你对细节部分的了解会随着你对项目的深入而逐渐增加。而有了主线后,你就有了着力点,就可以不断深入了。
但是,我们要学习的不只是这些接口的用法,要想从项目的接口设计上学到更多,这就需要你关注它所引导的风格,换句话说,就是它希望你怎样使用它,或是怎样在上面继续开发。
从一个项目的接口风格中,我们不难看出设计者的品位。我们常把编程视为一种艺术,而在接口的设计上就能窥见一二。这些内容是我们在学习软件设计时,应该慢慢品味的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件设计之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • Jxin
    1.最早自学的就是ruby,要不是因为找不到工作,可能就做不成javaer了。论快速搭建一个web项目,至今依旧是ruby on rails。一个多小时从无到有搭建一个博客系统的时候,信心爆棚。

    2.本篇,明天得再看看。get不到点。只能理解风格应该是说设计偏好。至于主线,从ruby这个demo里没能get到。


    3.spring。兼容(老版本以及各种场景),开放(提供规范和基础工具,方便各种“实现”自己写插件接入spring),与时俱进(springboot的推出,算得上破而后立),追求卓越(在迭代中改变接口命名,只为让原本达意的命名更达意)

    作者回复: Ruby 成于 Rails,也败于 Rails。

    2020-06-05
    8
  • 捞鱼的搬砖奇
    在 Spring 的源码中 接口 -> 抽象类->实现类,如 BeanDefinition -> AbstractBeanDefinition -> RootBeanDefinition。这样的设计风格。顶层接口规定定义,抽象类提供部分实现。用户需要扩展,可以选择从抽象类进行扩展,或从接口扩展。

    作者回复: 上一讲是 Spring,这一讲是 Ruby on Rails,这个评论让我有一种走错片场的感觉。:)

    2020-06-05
    4
  • Hank_Yan
    找主线,看风格。找主线看文章,看风格看接口。从上到下,从整体到局部。不过这也是正常读源码的一个步骤。

    作者回复: 太喜欢你这个评论了,这就应该是正常的步骤啊,可是很多人不知道。

    2020-06-07
    3
  • 王智
    Ruby on Rails这个设计在当时感觉很超前,也不知道现在的SpringBoot是不是借鉴了,感觉从SpringBoot上能看倒Ruby on Rails的身影, SpringBoot的约定大于配置,还SpringBoot把命简洁的页面,勾选之后就可以创建一个简单的SpringBoot项目等等,Ruby on Rails的设计在现在看来可能确实没什么,但在当时感觉这个设计就太超前了.

    作者回复: 你说得很对,Rails超前是全方位的,今天看来,很多东西都影响了全行业。

    2020-06-06
    1
    3
  • qinsi
    最早接触BDD是cucumber,当时觉得简直是magic。整个RoR框架也到处给人magic的感觉。但是软件开发不应该有magic,否则容易失控。RoR式微部分原因可能也是Ruby过于灵活了,印象中RoR有些严重的安全漏洞就是由此引发。此外Ruby的执行效率也逐渐落后于时代了。近年来有Crystal语言借由llvm复兴Ruby,加入了很多现代语言的特性,希望能有好结果。

    作者回复: 这是两个方面,使用者和开发者。使用者的角度,那是简单的,开发者的角度,需要理解那些 Magic。

    Ruby 有些问题其实动态语言的问题,在开发大型应用上,没有类型是一个很伤的地方。

    执行效率其实与使用程度是相关的,只要有更多的人在用,就会有更多的人来优化,如果没有人用,优化的动力自然就不强了。

    2020-06-05
    3
  • 阳仔
    理解软件中的接口设计,要抓住主线,可以从文档开始入手,了解软件设计者的风格品味,看看作者希望我们是如何使用这些接口的。
    我没用过Ruby,但是通过分析之后,其实它的接口设计中,整合了许多极佳的工程实践,提高编码效率,解放生产力,这些思想在软件设计的时候是可以学习和参考的

    作者回复: 能够把开发效率提高,也是一大推动力。

    2020-06-05
    3
  • 再来二两杜康酒
    好的设计要多从使用者角度考虑,是否有助于释放程序员精力,是否易用,是否有良好的可读性和可扩展性。自己先用,并在开始时就设定好边界,即使先只在一点上有所突破也比全面开花哪哪不灵要好。

    作者回复: 这个我完全同意!你说的单点突破实际上就是 MVP 的思路。

    2020-06-07
    2
  • Kǎfκã²⁰²⁰
    怀念RoR,起初用过,后来因为性能,我们都替换成Java了

    作者回复: 曾经沧海

    2020-06-05
    2
  • escray
    “优雅的编程接口,顺畅的开发过程”,虽然我也非常的喜欢 Ruby on Rails,却没有办法像老师这样精辟的总结提升。

    给我的感觉,RoR 在设计的时候非常的体贴程序员,并且采用了一大堆优秀的设计范式。

    看了文中对于 Rails 接口的分析,感觉更喜欢 Rails 了,可惜的确如同留言里面 @Jxin 说的那样,工作不好找,另外薪水不高。

    如果按照开发模式的变迁,那么现在是不是应该学习 Deno ? 请老师推荐一个比较有潜力的语言或者框架,Go 或者 TypeScript ?

    作者回复: 很快就轮到讲程序设计语言了,简言之,多学点。

    2020-06-05
    1
    2
  • 舀点米 | Titus Mi
    那python的Django是不是也有rails的问题?那flask呢?java的spring boot是更好的实践吗?
    另外rails应该也可以使用前后端分离吗?老师是否还可以再分享下,spring具体是如何越来越强大,使得rails落伍?spring和node如何联手超越rails的?

    作者回复: 从工程实践的角度看,Rails 是最好的,很多后来者抄袭了 Rails,比如,Django。Spring Boot 最近这些年进步很大,但依然不如 Rails。Spring Boot 其实就是把 Spring 这么多年积累的组件合到了一起,再加上嵌入式服务器的发展,大幅度地降低了开发难度。

    编程模型从 MVC 转向了 REST 服务,是一个重大的契机。Rails 自身的执行效率本来就是一个硬伤。Spring Boot 可以说抓住了新一波的浪潮,让 Java 重新回到了巅峰上。

    之所以 MVC 转向了 REST,要拜 Node.js 所赐,让前端有了大发展,这段分析在程序设计语言的加餐中。

    2020-06-19
    1
  • 六一王
    接触的第一个框架就是 rails,用起来确实很爽,今天看到此篇文章,让我对它更有敬意,而不会因为现在不就行,或者性能不够好,就看不起它,没有东西是绝对的好,或者绝对不好,今天全是对这个道理有更深层的理解了。
    我之后学习了JavaScript,转了前端,学习 Vue 框架,它使用虚拟dom将组件高度抽象化,使页面组件可以多端运行,比如node端,如此可以前后端同构,解决单页面应用的劣势,而保留其优势。
    模块如何拆解然后又如何组装,逻辑清晰。
    提供了很多全局组件和生命周期函数,以及其他方法,这些就是给程序员提供的接口,可以让我们在特定的场景让你更加关注功能需求的实现,而不是代码的实现细节,会自动帮你做好很多事情。
    并且使用了很多高阶函数,化繁为简,最终返回一个干净的只有核心逻辑的函数。即大量使用了函数式编程。
    学习的过程就是写一段简单的,特定场景代码,然后进行断点测试,看看源码中主要会走那些流程。然后大概就有了一条小主线。
    好的框架理解起来应该是容易的,清晰的。而那些不假思索写出来的面向过程的代码,如果不一行一行去看的话,就不知道问题出在哪里,甚至以后回过来看,都不知道自己是怎么写出这种代码的,就像写正则表达式一样,写完之后,自己都看不懂了。

    作者回复: 感谢你的分享,丰富了更多的内容。

    2020-06-08
    1
  • jakimli
    问个问题,如果说rails落伍的原因是因为Javascript,为什么没有演变成 javascript + rails后端服务这样的组合呢?

    作者回复: 在加餐里讲了 JavaScript 的兴起,实际上,Node.js 并没有真正意义上成为后端开发的主力,却促进了前端的发展,让前后端分离了,结果,后端借此兴起的是 Java。

    Rails 归根结底是有硬伤的,性能差。在没有了 MVC 的加持之后,Java 就重新回来了。

    2020-06-28
  • 蓝士钦
    关于接口想请教一下老师,我们平时在公司内部的二方库,是不是应该拆分成两个jar包,分为api模型包和一个实现包。对于大多数开发业务我们只关心一个系统的模型以及提供什么样的功能接口。拆分成不同包可以根据需要引入不同的实现包,而api和模型是共用的。 比如最近有个项目需要把查数据湖的报表改成差数据库,如果封装的足够好应该只要替换实现就可以不改一行代码达到目标。

    作者回复: 这其实是打包原则的事。从理论上说,分成两个是最好,只是实际情况很多人分不了那么干净。

    2020-06-11
收起评论
13
返回
顶部