《冒号课堂 编程范式与OOP思想》 - 书摘精要

(P5)

学会不如会学，会学不如会用，会用不如被用；

学会(知其所然) —— 掌握一些具体编程知识的初级程序员；

会学(知所以然) —— 能快速而深刻地理解技术并举一反三的程序员；

会用(人为我用) —— 能将所学灵活运用到实际编程设计之中的高级程序员；

被用(我为人用) —— 能设计出广为人用的应用程序(Application)、库(Library)、工具包(Toolkit)、框架(Framework)等的系统分析师和架构师；

(P5) 计算机专家 —— 发明出主流的设计模式、算法、语言乃至理论；

(P6) 知识之上是思想，思想之上是精神；

(P8) SGML - Standard, Generalized, Markup, Language;

(P11)

好的语言就是合适编程者和解决对象的语言；

计算机语言按其发展历程通常分为5代：机器语言、汇编语言、高级语言、面向问题语言、人工智能语言；

(P16)

得形而忘意，无异舍本逐末，

得意而忘形，方能游刃有余；

编程范式 (Programming Paradigm)

(P21)

大多数软件开发是以金钱而不是技术为中心的；

设计模式是软件的战术思想，架构是软件的战略决策；

(P40) 软件设计最重要的并不是编程语言，甚至也不是编程范式，而是抽象思维；

(P41) 与其说OOP更具重用性，不如说更具易用性；

(P51)

泛型编程 (Generic Programming) —— 将算法与其作用的数据分离，并将后者尽可能泛化，最大限度地实现算法重用；

STL - Standard Template Library;

(P66) 如果真想成为优秀的程序员，一定要尽可能地读原文书籍、文章和文档；

(P67) 对程序员来说，英语也是一门计算机语言，而且是必修的语言；

(P104)

同样的思想用在整体系统的结构设计上，则称为架构模式；用在局部模块的细节实现上，则称为设计模式；用在引导编程实践上，则称为编程范式；

设计模式有时被称为微架构(Micro Architecture)模式；

(P121) 编程水平的提升之道是：在实战中演练招法，在招法中领会心法，心法反过来提升招法，进而提高实战水平，如此循环往复呈螺旋式上升过程。正所谓熟能生巧，巧能生通；

(P124)

无论干哪一行，要想胜任愉快，离不开四样东西：才能、兴趣、方法和努力；

没有才能则难以胜任，

没有兴趣则难以愉快。

没有方法则事倍功半，

没有努力则一事无成；

(P134) 动态语言秉承的一个理念是：优化人的时间而不是机器的时间；

(P138) 无知与偏见总是相辅相成的；

(P141) 对一个程序员而言，编程语言乃立身之本；

(P192) 接口是纲，实现是目。纲若不举，目无以张；

(P199) 抽象 —— 尤其是数据抽象 —— 才是OOP的核心和起源；

(P214) 封装 —— 准确地说是信息隐藏 —— 则是将非本质、容易变化的部分隐藏起来；

(P218) 严格遵循开闭原则的软件，不应该修改老代码，只能增加新代码；

(P224) 一般不建议继承非抽象类，因而protected的意义就不大了；

(P243)

接口继承的作用不是为了让继承者重用被继承者的代码，而是为了在合适的场合被调用；

接口继承不是为了代码重用，而是为了代码被重用；

(P267) 提倡接口继承，慎用实现继承；

(P293)

具体类型是创建对象的模板，

抽象类型是创建类型的模板；

抽象数据类型的核心是数据抽象，

抽象类型的核心是多态抽象；

(P294) 合成的基础类只能是具体类型，不能是抽象类型；

(P297) 具体实例永远是为抽象思想服务的；

(P303) 抽象不是目的而是手段；

(P304)

具体类描述对象，重在实现；

抽象类描述规范，重在接口；

(P318) 多掌握一门语言，便多一扇领悟之门，多一条贯通之道；

(P334) 在早期的UML草案中，“合成”被(Grady Booch)称为Aggregation by Value，“聚合”被称为Aggregation by Reference;

(P337) 从关联(has-a关系)到聚合(owns-a关系)，再到合成(contains-a关系)，耦合度逐步加大；

(P364)

耦合度 低 --> 高：

[提倡]：

无耦合 (no coupling)

消息耦合 (message coupling)

数据耦合 (data coupling)

[限制]：

印记耦合 (stamp coupling)

控制耦合 (control coupling)

外部耦合 (external coupling)

[避免]：

公共耦合 (common coupling)

内聚耦合 (content coupling)

内聚度 高 --> 低：

[提倡]：

功能内聚 (functional cohesion)

信息内聚 (informational cohesion)

[限制]：

顺序内聚 (sequential cohesion)

通信内聚 (communicational cohesion)

过程内聚 (procedural cohesion)

[避免]：

时间内聚 (temporal cohesion)

逻辑内聚 (logical cohesion)

偶然内聚 (coincidental cohesion)

(P373) ISP(接口隔离原则)主张：不应强迫客户依赖那些它们不用的方法，多个专用的接口比单纯一个总接口好；

(P381) S-O-L-I-D 类级设计原则：

单一职责原则 (SRP - Single Responsibility Principle) —— 一个类应当只有一个变更的理由；

开闭原则 (OCP - Open-Closed Principle) —— 软件实体应对扩展开放，对修改封闭；

里氏代换原则 (LSP - Liskov Substitution Principle) —— 子类型必须能替代超类型；

接口隔离原则 (ISP - Interface Segregation Principle) —— 不应强迫客户依赖那些它们不用的方法；

依赖反转原则 (DIP - Dependency Inversion Principle) —— 抽象不应依赖细节，细节应当依赖抽象；

(P382) 包级设计原则：

发布重用等价原则 (REP - Release-Reuse Equivalency Principle) —— 重用的粒度即是发布的粒度；

共同闭包原则 (CCP - Common Closure Principle) —— 同在一个包中的类应对同类变化封闭；

共同重用原则 (CRP - Common Reuse Principle) —— 同在一个包中的类一起被重用；

无环依赖原则 (ADP - Acyclic Dependencies Principle) —— 在包的依赖图中不允许有环存在；

稳定依赖原则 (SDP - Stable Dependencies Principle) —— 朝着稳定的方向依赖；

稳定抽象原则 (SAP - Stable Abstractions Principle) —— 一个包的抽象度应与其稳定度相当；

(P404) C#中的 namespace 是逻辑包，assembly 是物理包；

(P438) 命令式OOP的一个弱点是：一个对象必须在获得另一个对象的标识后才能向其发送信息。这使得两个交流的对象在类型、个体和时间上发生了耦合；

(P441) 广度影响深度；

(P443) 设计原则高于设计模式，设计模式源于设计原则；