架构师训练营 - 第 2 周学习总结

从编程历史慢慢了解到了常用的一些OOD原则和使用，以及到架构中的应用场景，哪些只有在架构时才会思考的优缺点，收获满满

1、编程语言的历史演进过程

1.1、汇编语言，每一种CPU都有独特的机器语言，因而需要不同的汇编语言

1.2、早期的Basic语言，早期Basic语言虽然号称为“高级语言”，但保留了汇编语言的特征--地址（即行号）

1.3、结构化的Basic语言（Quick Basic 、Visual Basic等），结构化的Basic 语言仍然兼容传统的Basic，而且提供了更好的继承开发环境。

结构化的编程取消了“地址”和Goto语句，代之以集中程序控制“结构”，如：循环、条件等。

1.4、Perl语言，Perl是一种脚本语言，最强大的功能是正则表达式。但Perl的语法比较晦涩难懂。Perl是一种“伪”的面向对象语言。

1.5、C语言是一个结构化语言

1.6、C++向后兼容C的所有功能，并且提供了面向对象的编程机制。

1.6、Java是一个完全面向对象的语言，尤其是在当今的Internet编程领域，占领了绝对的市场。

1.7、编程语言是一种“抽象”的机制，问题是对“谁”来抽象：

领域问题--分析，抽象-->模型<--设计抽象，开发实现-->软件系统



2、面向对象编程的三要素（特征）

2.1、封装性（隐藏实现，抽象方法）

2.2、继承性（接口重用，多实现多子类）

2.3、多态性（对象互换的魔法，父类引用指向子类对象）

2.4、面向对象编程不是使用面向兑现的编程语言进行编程，而是利用多态特征进行编程。

2.5、面向对象分析是将客观世界，即编程的业务领域进行对象分析。

2.5.1、充血模型和贫血模型

所谓充血模型，是指Model 中既包括状态，又包括行为，是最符合面向对象的设计方式

所谓贫血模型，是指Model 中，仅包含状态(属性），不包含行为(方法），采用这种设计时，需要分离出DB层，专门用于数据库操作

2.5.2、领域驱动设计DDD(Domain-Driven Design )

2.6、面向对象设计的目的和原则

2.6.1、强内聚、低耦合，从而使系统易扩展-易于增加新的功能，更强壮-不容易被粗心的程序员破坏，可移植-能够在多样的环境下运行，更简单-容易理解、容易维护

2.6.2、为了达到上述设计目标，有人总结除了多种知道原则；“原则”是独立于变成语言的，甚至也可以用于非面向对象的编程语言中。

2.7、设计模式，设计模式是用于解决某一种问题的通用的解决方案。设计模式也是语言中立的。设计模式贯彻了设计原则。

2.8、框架是用来实现某一类应用的结构性的程序，是对某一类架构方案可复用的设计与实现：

如同架构结构的大厦的框架。

简化应用开发者的工作。

实现了多种设计模式，使应用开发者不需要花太大的利器，就能设计出结构良好的程序来

2.9、架构 VS 工具

架构调用应用程序代码

应用程序代码调用工具

架构师用框架保证架构的落地

架构师用工具提高开发效率

3.1、面向对象设计的基本原则

3.1.1、软件设计的“臭味”，一个“不好的”软件，会发出如下“臭味”：

僵硬 - 不易改变。僵化性（Rigidity）：很难对系统进行改动，因为每个改动都会迫使许多对系统其它部分的改动。

脆弱 - 只想改变A，结果B被意外破坏。脆弱性（Fragility）：对系统的改动会导致系统中和改动的地方无关的许多地方出现问题。

不可移植 - 不能适应环境的变化。牢固性（Immobility）：很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。

导致误用的陷阱 - 做错误的事比做正确的事更容易，引诱程序员破坏原有的设计。

粘滞性（Viscosity）：做正确的事情比做错误的事情要困难。不必要的复杂性（Needless Complexity）：设计中包含有不具任何直接好处的基础结构。

晦涩 - 代码难以理解。晦涩性（Opacity）：很难阅读、理解。没有很好的表现出意图。

过度设计、copy-paste代码。不必要的重复（Needless Repetition）：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。

3.2、OOD原则一：开/闭原则（OCP-Open/Closed Principle）

对于扩展是开放的（Open for extension）

对于更改是封闭的（Closed for modification）

简言之：不需要修改软件实体（类、模块、函数等），就应该能实现功能的扩展

3.3、OOD原则二：依赖倒置原则（DIP-Dependency Inversion Principle）

高层模块不能依赖底层模块，而是大家都依赖于抽象。

抽象不能依赖实现，而是实现依赖抽象。

DIP倒置了模块或包的依赖关系，以及开发顺序和职责

软件的层次化，高层决定低层，高层被重用

层次依赖关系：

策略（Policy）<-- 机制（mechanism）<-- 公用（utility）

3.4、OOD原则三:Liskov替换原则（LSP）

在Java/C++这样的静态类型语言中，实现OCP的关键在于抽象，而抽象的威力在于多态和继承。

若对每个类型T1的对象o1,都存在一个类型T2的对象o2，使得在所有针对T2编写的程序P中，用o1替换o2后，程序P的行为功能不变，则T1是T2的子类型。

简言之：子类型（subType）必须能够替换掉它们的基类型（base type）。

重构代码，提取共性到基类

3.5、框架的核心

好莱坞规则：Don't call me,I‘ll call you.

倒转的层次依赖关系

3.6、OOD原则四：单一职责原则（SRP-Single Responsibility Principle）

又被称为“内聚性原则（Cohesion）”，意为：一个模块的组成原色之间的功能相关性。

将它与引起一个模块改变的作用力相联，就形成了如下描述：一个类，只能有一个引起它的变化的原因。

3.7、OOD原则五：接口分离原则（ISP-Interface Segregation Priciple）

不应该强迫客户程序依赖它们不需要的方法。

ISP和SRP是相关的，都和”内聚性“有关。

SRP指出应该如何设计一个类---只能有一种原因才能促使类发生改变。

ISP指出应该如何设计一个接口---从客户的需要出发，强调不要让客户看到他们不需要的方法。