软件设计的5项基本原则
什么叫做技术好,好在哪里?
深度,深在哪里?
1、编程能力强? 对还是不对?
根本,编程能力强。真正写好代码,无论如何还是要编程能力强,不然只是泡沫。写好代码,
2、如何写好代码,如何做好软件设计?
糟糕的软件设计
糟糕的代码会带来糟糕的体验,强烈的冲突感,让人受不了。
僵硬 -不易改变
脆弱– 只想改A,结果B被意外破坏
牢固 -无法进行快速的拆分
粘滞-对现有软件做变更,糟糕的代码比优秀的代码更容易些
晦涩 – 代码难以理解()
过度设计 、copy-paste代码
代码首先是给人看的,其次才是给机器执行的?
如果软件是一次性的,那么就无所谓优秀,软件设计是否优秀,是在软件维护、变更的时候体现出来的。
软件为需求变更而设计。
优秀的程序员是什么样的?
- 优秀的程序员不会害怕需求变更,而是害怕没有需求变更。
- 没人用的软件,是无需求变更的。代表软件有活力
- 一开始就想到了,未来可能的发展变化方向,并未其做好了设计
- 无需求变更的话,优秀的程序员与糟糕的程序员没有区别了
- 优秀的程序员不会被动接受需求变更,而是主动引导需求变更。
- 之前的设计依然没有用处,所以不能被动的接受需求变更,要有引导的能力
- 优秀的程序员能掌控自己的代码
对结果负责
五大原则
一、开闭原则(OCP)
-
- OCP- Open/Closed Principle
- 对于扩展是开放的(Open for extension)
- 对于更改是关闭 (Closed for modification)
- 简而言之:不需要修改软件实体(类,模块,函数等),就能实现功能的扩展
- OCP- Open/Closed Principle
- 传统的扩展模块的方式就是修改模块的源代码。如何实现不修改而扩展呢?
- 关键是抽象
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)”意为:
- 一个模块的组成元素之间的功能相关性
- 将它与引起一个模块改变的作用力相联,就形成了如下描述:
- 一个类,只能有一个引起它的变化的原因
- 又被称为“内聚性原则(Cohesion)”意为:
- 什么是职责?
- 单纯谈论职责,每个人都会得出不同的结论
- 因此我们下一个定义:
- 一个职责是一个变化的原因。
违反SRP的例子
五、接口隔离原则(ISP)
- ISP – Interface Segregation Principle
- 不应该强迫客户程序依赖它们不需要的方法。