04 | 编程语言的进化

“我的演讲”，我也打不开。。

对象范式的原始概念其实根本不包括类和继承，只有1，程序由对象组成，2，对象之间互相发送消息，协作完成任务。最初世界上第一个面向对象语言是 Simula-67，第二个面向对象语言是 Smalltalk-71。Smalltalk 受到了 Simula-67 的启发，基本出发点相同,但是最大的不同是Smalltalk是通过发消息来实现对象方法调用，而Simula是直接调用目标对象的方法。Bjarne Stroustrup 在博士期间深入研究过 Simula，非常欣赏其思想，C++的面向对象思路直接受其影响，因为调用目标对象的方法来“传递消息”需要事先知道这个对象有哪些方法，因此，定义对象本身有哪些方法的“类”和“继承”的概念，一下超越了对象本身，而对象只不过是类这个模子里造出来的东西，反而不重要。随着C++的大行其道，继承和封装变成了面向对象世界的核心概念，OOP 至此被扭曲为 COP （ Class Oriented Programming，面向类程序设计）。 但是COP这套概念本身是有缺陷的：每个程序员似乎都要先成为领域专家，然后成为领域分类学专家，然后构造一个完整的继承树，然后才能 new 出对象，让程序跑起来。 到了 1990 年代中期，问题已经十分明显。UML 中有一个对象活动图，其描述的就是运行时对象之间相互传递消息的模型。1994 年 Robert C. Martin 在《 Object-Oriented C++ Design Using Booch Method 》中，曾建议面向对象设计从对象活动图入手，而不是从类图入手。而 1995 年出版的经典作品《 Design Patterns 》中，建议优先考虑组合而不是继承，这也是尽人皆知的事情。这些迹象表明，在那个时候，面向对象社区里的思想领袖们，已经意识到“面向类的设计”并不好用。只可惜他们的革命精神还不够，delphi 之父在创建.Net Framework 的时候，曾经不想要继承，在微软内部引起了很大的争议，最后是向市场低头，加上了继承。 2000 年后，工程界明确的提出：“组合比继承重要，而且更灵活”，Go和Rust也许是第一批明确的对这种思路进行回应的语言，他们的对象根本不需要类本身来参与，也能完成对象范式的多态组合。 历史让 C++走上了舞台，历史也终将让 COP 重新回到 OOP 的本来面目

关于许老师说关于继承的看法，我拜读后深有同感。尤其多层的继承，理解成本多项式上升。有点像，你想了解清楚眼前的这位妹子，不但要知道她已有的一切（所有逻辑成员），还要知道她所有祖上（继承链）的一切（包括private），更要知道这位女孩做了什么叛逆行为（override），还不得不知道，这些叛逆行为，会对祖传的既有秘方产生怎样的影响（调用override函数的函数）… 回顾一下最近自己工作的代码，的确不少的设计，最后会倾向于组合的方式。原本的想法主要是感觉，用继承的话，更像是可以去为了聊天而去相亲…不好意思说错了，是为了面向对象而去面向对象，一个月后，自己理解这部分设计也有不小的成本。读了许老师的课，才从更深层次的意识到这个特性的确有它天生的缺陷。

我的工作是Python后台。 Python开发效率是相当快的，能想到的功能基本都有比较稳定的库，开发起来贼快。 我公司三个后台，每个人写的Python都不一样，一个喜欢面向对象，一个喜欢类似过程式那种，另一个喜欢自创式。 自己开发功能虽然相当快，但是一旦涉及到维护其它人的代码，效率就一落千丈，总是看不懂或者想要重构😂😂。 最近裸辞了在家里学go，第一眼就爱上了这个语言。

使用java四年了，看到封装，继承，多态的描述，特别精准，又有了更深刻的理解。 不了解go语言，比如有一个表单的基类，里面有基本的处理，子类继承这个基类，有自己特殊的实现。 这种情况，如何用组合实现呢？

编程框架和编程范式具体有什么区别呢？感觉都具备约束、规范的作用。

变量不可变我理解的就是一切变量皆常量（或者只能被初始化一次），但是函数没有副作用就不懂了，副作用具体指啥？为什么内部有IO行为的函数就有副作用呢？

如果你想用函数式编程，你需要重修数据结构这门课程，大学里面学的数据结构是不顶用了。那应该学习什么可以给个建议吗？

感恩大佬分享 随喜大佬 学生是java使用者 个人认为类之间具备‘is-a’的关系这种情况时 还是很有必要的；继承使所有子类公共的部分都放在了父类，使得代码得到共享，避免重复。 这是学生一点自己的理解 望老师批评指正，再次感恩老师分享这么好的课程 我当奉持 如法修行

后端服务可能趋向于标准化或者固定化，可能前端才是真正的战场。