Hello World
究竟是那些类应该被组合成一个组件呢？三个与构建组件相关的基本原则：
REP：复用/发布等同原则软件复用的最小粒度应等同于其发布的最小粒度。
CCP：共同闭包原则我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中。
CRP：共同复用原则不要强迫一个组件的用户依赖他们不需要的东西。
三个原则之间彼此存在着竞争关系。软件架构师的任务就是要在着三个原则中间进行取舍。一个项目在组件结构设计上的重心是根据该项目的开发时间和成熟度不断变动的，我们对组件结构的安排主要与项目开发的进度和它被使用的方式有关，与项目本身功能的关系其实很小。
组件是软件的部署单元，是整个软件系统在部署过程中可以独立完成部署的最小实体。
无论采用哪种部署形式，设计良好的组件都应该永远保持可被独立部署的特性，这同时也意味着这些组件应该可以被单独开发。
在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。
本周状态很差。每天睡得很晚，睡前也没做什么有意义的事。早上总是要起床两次，工作动力也不大够。吃饭也很凑合。
正方形/长方形问题是一个著名（或者说臭名远扬）的违反 LSP 的设计案例。在这个案例中，Square 类并不是 Rectangle 类的子类型。
随着时间的推移，LSP 逐渐演变成了一种更广泛的、指导接口与其实现方式的设计原则。
没看明白出租车调度服务系统那个反面案例，跟 LSP 的关系是什么？最后没有给出符合 LSP 的做法。
设计良好的计算机软件应该易于扩展，同时抗拒修改。
换句话说，一个设计良好的计算机系统应该在不需要修改的前提下就可以轻易被扩展。
OCP 是我们进行系统架构设计的主导原则，其主要目标是让系统易于扩展，同时限制其每次被修改所影响的范围。实现方式是通过将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高阶组件不会因低阶组件被修改而受影响。
SOLID 原则是用来帮助我们定义软件架构中的组件和模块的。
对于 SRP 的最终描述：
任何一个软件模块都应该只对某一类行为者负责。
SRP 强调，不同行为者所依赖的代码，一定要被分开。
一个架构设计良好的应用程序应该将状态修改的部分和不需要修改状态的部分隔离成单独的组件，然后用合适的机制来保护可变量。
软件架构师应该着力于将大部分处理逻辑都归于不可变组件中，可变状态组件的逻辑应该越少越好。
事件溯源，我们只存储事务记录，不存储具体状态。当需要具体状态时，我们只要从头开始计算所有的事务即可。
如果我们有足够大的存储量和处理能力，应用程序就可以用完全不可变的、纯函数式的方式来编程。
C++ 作为一种面向对象编程语言，反而破坏了 C 的完美封装性。（C++ 编译器要求类的成员变量必须在该类的头文件中声明。）
面向对象编程在继承性方面并没有开创出新，但是的确在数据结构的伪装性上提供了相当程度便利。
多态其实不过就是函数指针的一种应用。面向对象编程语言虽然在多态上并没有理论创新，但它们也确实让多态变得更安全、更便于使用了。
面向对象编程到底是什么？对一个软件架构师来说，其含义应该是非常明确的：面向对象编程就是以多态为手段来对源代码中的依赖关系进行控制的能力，这种能力让软件架构师可以构建出某种插件式架构，让高层策略性组件与底层实现性组件相分离，底层组件可以被编译成插件，实现独立于高层组件的开发和部署。