左耳听风
陈皓
网名“左耳朵耗子”,资深技术专家,骨灰级程序员
立即订阅
40357 人已学习
课程目录
已完结 108 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 | 洞悉技术的本质,享受科技的乐趣
免费
01 | 程序员如何用技术变现(上)
02 | 程序员如何用技术变现(下)
03 | Equifax信息泄露始末
04 | 从Equifax信息泄露看数据安全
05 | 何为技术领导力?
06 | 如何才能拥有技术领导力?
07 | 推荐阅读:每个程序员都该知道的知识
08 | Go语言,Docker和新技术
09 | 答疑解惑:渴望、热情和选择
10 | 如何成为一个大家愿意追随的Leader?
11 | 程序中的错误处理:错误返回码和异常捕捉
12 | 程序中的错误处理:异步编程以及我的最佳实践
13 | 魔数 0x5f3759df
14 | 推荐阅读:机器学习101
15 | 时间管理:同扭曲时间的事儿抗争
16 | 时间管理:如何利用好自己的时间?
17 | 故障处理最佳实践:应对故障
18 | 故障处理最佳实践:故障改进
19 | 答疑解惑:我们应该能够识别的表象和本质
20 | Git协同工作流,你该怎么选?
21 | 分布式系统架构的冰与火
22 | 从亚马逊的实践,谈分布式系统的难点
23 | 分布式系统的技术栈
24 | 分布式系统关键技术:全栈监控
25 | 分布式系统关键技术:服务调度
26 | 分布式系统关键技术:流量与数据调度
27 | 洞悉PaaS平台的本质
28 | 推荐阅读:分布式系统架构经典资料
29 | 推荐阅读:分布式数据调度相关论文
30 | 编程范式游记(1)- 起源
31 | 编程范式游记(2)- 泛型编程
32 | 编程范式游记(3) - 类型系统和泛型的本质
33 | 编程范式游记(4)- 函数式编程
34 | 编程范式游记(5)- 修饰器模式
35 | 编程范式游记(6)- 面向对象编程
36 | 编程范式游记(7)- 基于原型的编程范式
37 | 编程范式游记(8)- Go 语言的委托模式
38 | 编程范式游记(9)- 编程的本质
39 | 编程范式游记(10)- 逻辑编程范式
40 | 编程范式游记(11)- 程序世界里的编程范式
41 | 弹力设计篇之“认识故障和弹力设计”
42 | 弹力设计篇之“隔离设计”
43 | 弹力设计篇之“异步通讯设计”
44 | 弹力设计篇之“幂等性设计”
45 | 弹力设计篇之“服务的状态”
46 | 弹力设计篇之“补偿事务”
47 | 弹力设计篇之“重试设计”
48 | 弹力设计篇之“熔断设计”
49 | 弹力设计篇之“限流设计”
50 | 弹力设计篇之“降级设计”
51 | 弹力设计篇之“弹力设计总结”
52 | 管理设计篇之“分布式锁”
53 | 管理设计篇之“配置中心”
54 | 管理设计篇之“边车模式”
55 | 管理设计篇之“服务网格”
56 | 管理设计篇之“网关模式”
57 | 管理设计篇之“部署升级策略”
58 | 性能设计篇之“缓存”
59 | 性能设计篇之“异步处理”
60 | 性能设计篇之“数据库扩展”
61 | 性能设计篇之“秒杀”
62 | 性能设计篇之“边缘计算”
63 | 区块链技术的本质
64 | 区块链技术细节:哈希算法
65 | 区块链技术细节:加密和挖矿
66 | 区块链技术细节:去中心化的共识机制
67 | 区块链技术细节:智能合约
68 | 区块链技术 - 传统金融和虚拟货币
69 | 程序员练级攻略:开篇词
70 | 程序员练级攻略:零基础启蒙
71 | 程序员练级攻略:正式入门
72 | 程序员练级攻略:程序员修养
73 | 程序员练级攻略:编程语言
74 | 程序员练级攻略:理论学科
75 | 程序员练级攻略:系统知识
76 | 程序员练级攻略:软件设计
77 | 程序员练级攻略:Linux系统、内存和网络
78 | 程序员练级攻略:异步I/O模型和Lock-Free编程
79 | 程序员练级攻略:Java底层知识
80 | 程序员练级攻略:数据库
81 | 程序员练级攻略:分布式架构入门
82 | 程序员练级攻略:分布式架构经典图书和论文
83 | 程序员练级攻略:分布式架构工程设计
84 | 程序员练级攻略:微服务
85 | 程序员练级攻略:容器化和自动化运维
86 | 程序员练级攻略:机器学习和人工智能
87 | 程序员练级攻略:前端基础和底层原理
88 | 程序员练级攻略:前端性能优化和框架
89 | 程序员练级攻略:UI/UX设计
90 | 程序员练级攻略:技术资源集散地
91 | 程序员面试攻略:面试前的准备
92 | 程序员面试攻略:面试中的技巧
93 | 程序员面试攻略:面试风格
94 | 程序员面试攻略:实力才是王中王
95 | 高效学习:端正学习态度
96 | 高效学习:源头、原理和知识地图
97 | 高效学习:深度,归纳和坚持实践
98 | 高效学习:如何学习和阅读代码
99 | 高效学习:面对枯燥和量大的知识
左耳听风
登录|注册

38 | 编程范式游记(9)- 编程的本质

陈皓 2018-02-08
前面我们讲了各式各样的不同语言的编程范式,从 C 语言的泛型,讲到 C++ 的泛型,再讲到函数式的 Map/Reduce/Filter,以及 Pipeline 和 Decorator,还有面向对象的多态通过依赖接口而不是实现的桥接模式、策略模式和代理模式,以及面向对象的 IoC,还有 JavaScript 的原型编程在运行时对对象原型进行修改,以及 Go 语言的委托模式……
所有的这一切,不知道你是否看出一些端倪,或是其中的一些共性来了?

两篇论文

1976 年,瑞士计算机科学家,Algol W,Modula,Oberon 和 Pascal 语言的设计师 Niklaus Emil Wirth写了一本非常经典的书《Algorithms + Data Structures = Programs》(链接为 1985 年版) ,即算法 + 数据结构 = 程序。
这本书主要写了算法和数据结构的关系,这本书对计算机科学的影响深远,尤其在计算机科学的教育中。
1979 年,英国逻辑学家和计算机科学家 Robert Kowalski 发表论文 Algorithm = Logic + Control,并且主要开发“逻辑编程”相关的工作。
Robert Kowalski 是一位逻辑学家和计算机科学家,从 20 世纪 70 年代末到整个 80 年代致力于数据库的研究,并在用计算机证明数学定理等当年的重要应用上颇有建树,尤其是在逻辑、控制和算法等方面提出了革命性的理论,极大地影响了数据库、编程语言,直至今日的人工智能。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《左耳听风》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(33)

  • 楊_宵夜
    Roger的留言, 本人不才, 想试着从"Control标准化"和"代码可重用"的角度来回答下:
    仔细看那个检查表单信息的例子, 叫做check_form_XXX(), 是针对特定的一个form的, 那么自然而然会有check_form_YYY()和check_form_ZZZ()等等...

    所以说, 这个form校验例子中,
    1. 最简单的Control部分就是遍历表单fields.
    2. 然后, 虽然是不同的field, 但相同的type是做相同逻辑的校验;
    3. 如果还想提供"将整个form拆成不同的part, 用并发来遍历"这种Control的话, 抽象出来的check_form()函数还可以提供并发的版本;

    那么单单是以上3点, 全部都是"可标准化"的, 并且"可重用"的, 并不影响<业务的logic>;

    那么, 当有了check_from()这个Control之后, 真正决定业务的<业务的logic>, 有:
    1. 每个field分别是什么type? 是text? 是password? 还是email?
    2. 每个field的最低长度是多少? 类似的还有每个field的最大长度?
    3. 等等...

    以上的问题, 决定了这个field通过校验的条件是什么?
    而这个条件是无法"标准化"的, 因为一个复杂系统的每个form的field不可能是一模一样的;
    所以这些"条件", 就由陈老师写出的DSL来提供;

    因此最后就变成了, check_form()提供一套"标准"来校验每个表单, 而每个表单只需要告诉check_form()说: "我有这些东西, 你帮我校验一下"; 而这样的说法, 又有了些委托模式的味道了;

    总而言之, 个人愚见: Control和Logic部分的一个肉眼可见的界线就是: 是否可以标准化??
    因本人较熟悉Java, 再扩展来说, 全局的工具类就是一种全局Control, 而一个类中的private方法大致可以认为是这个类中的Control. (仅为一种思路, 未经推敲);
    2018-02-13
    21
  • mingshun
    自从写业务的这几年来,做得最多的就是分离 Logic 和 Control。无论是编写新代码还是重构旧代码,都是从这个方向努力,目标是写出让团队里每个人都能轻松看得懂的代码。也用过许多语言,像 C、C++、Java、Golang、Lua、JS、Ruby、Elixir、Red……虽然思维模式和习惯玩法各异,但编程的本质是一样的。毕竟代码写出来是给人看的。如果人都很难看懂,又谈何优化和改进代码?!

    作者回复: 赞👍

    2018-05-18
    13
  • SamZhou
    是处理什么(logic),怎么做(control),沟通方式(数据结构)?
    2018-02-10
    10
  • vvsuperman
    有没推荐阅读,逻辑和控制的意思实在不太懂
    2018-03-12
    3
  • nanquanmama
    焕然大悟
    2018-02-08
    3
  • 业余爱好者
    逻辑和控制的区别让我想起了数据结构的逻辑结构和存储结构。业务逻辑不关心控制的实现,数据结构的逻辑结构同样不关心数据结构的存储结构(是为抽象数据类型)。前者是对后者的抽象,只关心问题是什么,而不太关心如何解决问题,前者是宏观,后者是微观,前者是业务,后者是实现。
    2019-05-04
    2
  • songgoogle
    如果做过保险业务的同学应该就会懂一点什么是控制逻辑什么是业务本身了,控制逻辑就如何从你下单到购买的流程,保险业务逻辑就是如何计算保费等等,个人的一点点理解
    2019-03-23
    2
  • Roger
    还是不太明白 控制和逻辑的关系,检查表单的那个例子从我的理解来看已经是逻辑了。
    2018-02-09
    2
  • 帅广应s
    这段时间,正好在用python写一个从hive查数据,自动发邮件给运营产品的系统。借鉴了hadoop yarn的状态机后,整个逻辑结构清晰多了。但是也只是知道这样做可以解决问题,看了这篇文章后知道了为什么得这么做。感觉自己又上升了一个level ……
    2018-02-08
    2
  • edisonhuang
    程序=算法+数据结构
    算法=逻辑+控制
    如果将 Logic 和 Control 部分有效地分开,那么代码就会变得更容易改进和维护
    大部分混乱的代码就是把逻辑和控制混在一起了,导致难以阅读和维护。而逻辑才是我们真正要关心的问题,他解决了做什么。控制只是操作计算机的具体实现,解决了怎么做。二者关系就好像做正确的事和把事情做正确。其实我们真正关注的只是正确的事,这是战略层面,而把事情做正确是执行层面,有效解除二者的耦合是改善的重要一步
    2019-06-26
    1
  • 涛哥迷妹
    个人觉得 Data Structure 才是 What, Logic 是 do What , Control 是 how to do
    2019-06-20
    1
  • caohuan
    看完 耗子哥的文章,我知道 为什么我还是一枚 码农了,代码 没有解耦,业务和控制代码 糅合在一起,虽然 我会一点 面向对象的 5大原则,也看过 重构的书籍,一直在模仿表层,没琢磨本质,所以 代码 既丑陋,可读性很差,知道有问题,得去提高了
    2018-11-07
    1
  • favorlm
    老师,您好,实际的编程工作中,我很想融合,但是发现处处都是方法,无法选择
    2018-05-05
    1
  • fsj
    逻辑和控制不太好理解,粗浅的觉得,控制是逻辑的实现,逻辑是唯一的,控制是多样的,以后再慢慢体会。
    通过检查表单的例子,学会一个技能,以后写业务逻辑,先思考能不能通过某种方式(比如DSL,状态机等)完整的表达逻辑,然后在写控制,尽量避免逻辑被分散在多个控制之中
    2018-04-06
    1
  • Chris
    理解并认识到编程的本质,才真正可能跳出代码搬运工的圈子,感谢老师!
    2018-02-09
    1
  • 恩言
    言不由衷的喜欢啊,真的好。
    2018-02-08
    1
  • 磉盘
    帮助我理解了mvc模式
    2019-09-24
  • wynying
    这一讲很受启发
    2019-09-02
  • 2k
    真棒
    2019-04-14
  • 李强
    这两篇论文都说了数据和处理逻辑分离,分离就是一种分层,就像冯诺伊曼计算机体系,就像我们现在广泛使用的MVC框架,本质上都是分离,将相近的东西放到一起。
    2019-04-02
收起评论
33
返回
顶部