代码整洁之道--读后总结

一、软件架构设计的目标:
用最小的人力成本来满足构建和维护该系统的需求,更要在一段时间内持续满足后续需求
二、软件架构定义
从架构学角度分析,在一定程度上能够做到抓大放小,把握重点,但是也不可避免地错失某些重要的细节信息
三、软件架构师职责
更关注系统的整体架构,而不是具体的功能和系统行为的实现,必须创建出一个可以让功能实现起来更容易、修改起来更简单、扩展起来更轻松的软件架构
四、三大编程范式
1、结构化编程:对程序控制权的直接转移进行了规范和限制
2、面向对象编程:对程序控制权的间接转移进行了规范和限制
3、函数式编程:对程序的赋值进行了限制和规范(核心是想:不变性)
4、结构化编程范式最大启发是:在架构设计领域,功能性降解拆分仍然是最佳实践之一
5、面向对象编程就是以多态为手段对源代码的依赖关系进行控制的能力,这种能力让架构师可以构建出某种插件式架构,让高层策略性组件与底层实现性组件相分离.底层组件可以编译成插件,实现独立于高层组件的开发和部署
6、面向函数式编程启发:架构师应该着力于将大部分处理逻辑都归为不可变组件中,可变状态的组件越少越好
五、solid原则
SOLID 原则是面向对象设计（OOD）的五个基本原则，由 Robert C. Martin 提出。这些原则旨在提高软件的可维护性、灵活性和可扩展性。以下是每个原则的详细介绍：

1. 单一职责原则（Single Responsibility Principle, SRP）：
   每个类应该只有一个改变的理由，即一个类应该只负责一项任务或功能。这有助于使类更加独立，易于理解和测试。
   例如，如果有一个类负责两个不同的职责（如报表生成和数据库操作），则应该将其拆分为两个类，每个类只负责单一的功能。
2. 开放/封闭原则（Open/Closed Principle, OCP）：
   软件实体（如类、模块、函数等）应该对扩展开放，对修改封闭。这意味着应该能够在不修改现有代码的情况下扩展功能。
   例如，可以通过继承和多态来添加新功能，而不是修改现有的类。这有助于减少对现有代码的影响，使系统更加稳定。
3. 里氏替换原则（Liskov Substitution Principle, LSP）：
   子类应该能够替换其基类而不影响程序的正确性。这意味着子类的对象应该能够在程序中代替基类的对象，而不改变程序的预期行为。(主要体现在继承)
   例如，如果有一个函数接受基类类型的参数，那么传递该基类的任何子类对象给该函数都应该能够正确工作。
4. 接口隔离原则（Interface Segregation Principle, ISP）：
   不应该强迫客户端依赖于它们不使用的接口。这意味着应该创建细粒度的接口，客户端只需要知道它们需要使用的方法。
   例如，如果一个接口有多个方法，但某个实现类只需要使用其中的一部分，那么应该将接口拆分，以便实现类只实现它需要的那部分接口。
5. 依赖倒置原则（Dependency Inversion Principle, DIP）：
   高层模块不应该依赖于低层模块，它们都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。这意味着在代码中应该依赖于接口和抽象类，而不是具体的实现类。(依赖关系应该多引用抽象,而非具体实现)
   例如，如果一个高层的类需要访问数据库，它不应该直接依赖于具体的数据库实现，而应该依赖于一个抽象的数据库接口，具体的数据库实现类应该实现这个接口。

遵循 SOLID 原则有助于创建更加灵活、可重用和可维护的代码。然而，应用这些原则时也需要考虑实际情况，避免过度设计。在实际开发过程中，应该根据项目的具体需求和上下文来合理地应用这些原则。

六、组件聚合
1、复用/发布等同原则:软件复用的最小粒度等同于其发布的最小粒度
2、共同闭包原则:应该将相同目的而修改的类放在同一个组件中,将不同目的而修改的类放在不同的组件中
3、共同复用:不要强迫用户依赖不需要的东西(类)
七、组件耦合
1、组件依赖关系图中不能出现环,如果有,需要进行避免
2、自上而下设计,从应用层面开始设计
3、稳定依赖原则:依赖关系必须指向更稳定的方向,可以借助接口抽象进行解耦
4、稳定抽象原则:一个组件的抽象化程度应该与其稳定性保持一致
八、软件架构工作实质
1、规划如何将系统切分为组件,并安排好组件之间的排列关系,以及组件之间互相通信的方式,其策略就是要在设计中尽可能长时间保留尽可能多的可选项
2、优秀的架构师应该让高层策略与实现细节脱钩,使其策略部分不需要关心底层实现,同样也不依赖相关细节,架构师在做方案决策时,越晚越好,尽可能保留多选项
九、独立性
1、一个设计良好的架构应该通过保留可选项的方式,让系统在任何情况下都能方便地做出必要的变更
2、数据库与业务逻辑应该是毫无关系的,数据库应该是业务逻辑间接使用的工具,业务逻辑不需要了解数据库的结构,可以使用一个接口将数据库与业务逻辑隔离,从而隐藏数据库
3、一个系统的架构应该着重于展示系统本身设计(用例),而并非该系统使用的框架和展现形式