软件设计的5项基本原则

什么叫做技术好，好在哪里？

深度，深在哪里？

1、编程能力强？ 对还是不对？
根本，编程能力强。真正写好代码，无论如何还是要编程能力强，不然只是泡沫。写好代码，

2、如何写好代码，如何做好软件设计？

糟糕的软件设计

糟糕的代码会带来糟糕的体验，强烈的冲突感，让人受不了。

僵硬 -不易改变
脆弱– 只想改A，结果B被意外破坏
牢固 -无法进行快速的拆分
粘滞-对现有软件做变更，糟糕的代码比优秀的代码更容易些
晦涩 – 代码难以理解（）
过度设计 、copy-paste代码

代码首先是给人看的，其次才是给机器执行的？

如果软件是一次性的，那么就无所谓优秀，软件设计是否优秀，是在软件维护、变更的时候体现出来的。

软件为需求变更而设计。

优秀的程序员是什么样的？

• 优秀的程序员不会害怕需求变更，而是害怕没有需求变更。
  • 没人用的软件，是无需求变更的。代表软件有活力
  • 一开始就想到了，未来可能的发展变化方向，并未其做好了设计
  • 无需求变更的话，优秀的程序员与糟糕的程序员没有区别了
• 优秀的程序员不会被动接受需求变更，而是主动引导需求变更。
  • 之前的设计依然没有用处，所以不能被动的接受需求变更，要有引导的能力
• 优秀的程序员能掌控自己的代码
  对结果负责

五大原则

一、开闭原则（OCP）

• • OCP- Open/Closed Principle
    • 对于扩展是开放的(Open for extension)
    • 对于更改是关闭 (Closed for modification)
    • 简而言之：不需要修改软件实体（类，模块，函数等），就能实现功能的扩展

• 传统的扩展模块的方式就是修改模块的源代码。如何实现不修改而扩展呢？
  • 关键是抽象

OCP举例：

通过接口进行依赖，，不要直接让button直接依赖dialler

增加一个新的实现类，

一个类文件开发（测试）完成，就永远不再打开不再写。

二、依赖倒转原则（DIP）

接口应该是属于上层的，

• DIP – Dependency Inversion Principle
  • 高层模块不能依赖底层模块，而是大家都依赖于抽象；
  •  抽象不能依赖于实现，而是实现依赖抽象。
• DIP倒转了什么？
  • 模块或包的依赖关系
  •  开发顺序和职责
• 软件的层次化
  • 高层决定底层
  •  高层被重用

DIP最佳实践
恐惧和贪婪，反向思考。

•  我们在开发的程序如何就能处理HTTP请求了？
  • servelet 如何做到的？
  •  专业：
• 框架的核心：好莱坞
  • Don’t call me，I’ll call you
  •  如何设计、开发一个框架
  • 反应式微服务框架

三、里氏替换原则 Liskov原则（LSP）

• Liskov Substitution Principle
  • 若对每个类T1的对象o1，都存在一个类型T2的对象o2，使得在所有针对T2编写的程序P中，用o1替换o2后，程序P的行为功能不变，则T1是T2的子类型
  • 简而言之，子类型（sub type）必须能够替换掉它们的基类型（base type）

子类override 父类的方法后，抛出的exception是父类方法抛出的exception的父类还是子类？

违反LSP的案例 – JDK中的错误设计

四、单一职责原则（SRP）

• SRP – Single Responsibility Principle
  • 又被称为“内聚性原则（Cohesion）”意为：
    • 一个模块的组成元素之间的功能相关性
  • 将它与引起一个模块改变的作用力相联，就形成了如下描述：
    • 一个类，只能有一个引起它的变化的原因
• 什么是职责？
  • 单纯谈论职责，每个人都会得出不同的结论
  • 因此我们下一个定义：
    • 一个职责是一个变化的原因。

违反SRP的例子

五、接口隔离原则（ISP）

• ISP – Interface Segregation Principle
  • 不应该强迫客户程序依赖它们不需要的方法。