Create 《架构整洁之道》读书笔记 - 设计原则篇.md

_posts/《架构整洁之道》读书笔记 - 设计原则篇.md

@@ -0,0 +1,60 @@
+---
+title: 《架构整洁之道》读书笔记 - 设计原则篇
+date: "2024-12-11"
+image: 
+headerImage: false
+tag:
+  -
+star: true
+category: blog
+author: Ai.Haibara
+excerpt: 
+theme: fancy
+---
+
+## 概述
+
+
+## SOLID原则
+
+- SRP：单一职责原则。 该设计原则是某于康威圧律（Conway's Law）的一个推论——一个软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构。这样，每个软件模块都有且只有一个需要被改变的理由。
+- OCP：开闭原则。 该设计原则是由 Bertrand Meyer 在 20 世纪 80 年代大力推广的，其核心要素是：如果软件系统想要更容易被改变，那么其设计就必须允许新增代码来修改系统行为，而非只能靠修改原来的代码。
+- LSP：里氏替换原则。 该设计原则是 Barbara Liskov 在 1988 年提出的一个著名的子类型定义。简单来说，这项原则的意思是如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换。
+- ISP：接口隔离原则。 这项设计原则主要告诫软件设计师应该在设计中避免不必要的依赖。
+- DIP：依赖反转原则。 该设计原则指出高层策略性的代码不应该依赖实现底层细节的代码，恰恰相反，那些实现底层细节的代码应该依赖高层策略性的代码。
+
+
+### 单一职责原则
+
+每个模块都应该只做一件事。
+
+任何一个软件模块都应该有且仅有一个被修改的原因。
+
+任何一个软件模块都应该只对某一类行为者负责。
+
+单一职责原则主要讨论的是函数和类之间的关系——但是它在两个讨论层面上会以不同的形式出现。在组件层面，我们可以将其称为共同闭包原则（Common Closure Principle)，在软件架构层面，它则是用于奠定架构边界的变更轴心（Axis of Change）
+
+### 开闭原则
+
+设计良好的计算机软件应该易于扩展，同时抗拒修改。
+
+一个设计良好的计算机系统应该在不需要修改的前提下就可以轻易被扩展。
+
+### 里氏替换原则
+
+如果对于每个类型是 S 的对象 o1 都存在一个类型为 T 的对象 o2，能使操作 T 类型的程序 P 在用 o2 替换 o1 时行为保持不变，我们就可以将 S 称为 T 的子类型。
+
+LSP 可以且应该被应用于软件架构层面，因为一旦违背了可替换也该系统架构就不得不为此增添大量复杂的应对机制。
+
+### 接口隔离原则
+
+在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。从源代码层次来说，这样的依赖关系会导致不必要的重新编译和重新部署，对更高层次的软件架构设计来说，问题也是类似的。
+
+任何层次的软件设计如果依赖了它并不需要的东西，就会带来意料之外的麻烦。
+
+### 依赖反转原则
+
+1. 应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。同时，对象的创建过程也应该受到严格限制，对此，我们通常会选择用抽象工厂（abstract factory）这个设计模式。
+2. 不要在具体实现类上创建衍生类。
+3. 不要覆盖（override）包含具体实现的函数。
+4. 应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物的名字。