架构师课程学习第二周心得

对代码重构有了新的认识,了解到如何重构是好的,如果重构是坏的/难受的。还有有点期待后面讲具体设计模式的使用。
课程笔记内容如下:
软件设计原则
1.面向对象编程与面向对象分析
1.充血模型
2.贫血模型
3.领域驱动设计DDD
2.面向对象的设计目的与原则
1.目的:强内聚、低耦合、从而使系统
易扩展:方便新增功能
更强壮:不容易被粗心的程序员破坏
可移植:能够在多样的环境下运行
更简单:容易理解、容易维护
2.原则:各种总结原则
3.框架:
1.用来实现某一类应用的结构性程序,对某一类架构方案可复用与实现
2.不同领域的框架:
4.框架 VS 工具
1.junit是框架还是工具?框架
2.log4j是框架还是工具?工具
架构师用框架保证架构落地,架构师用工具提高开发效率
5.UML小练习:
拨打电话的Use Case描述:
1.我们按下数字按钮,屏幕显示号码,扬声器发出按键声音
2.我们按下send按钮,系统接通无线网络,同时屏幕上显示正在拨号
识别语句中隐藏的对象:
类图:

合作图

软件设计的“臭味”:
1.僵硬;2.脆弱;3.不可移植;4.导致误用的陷阱;5.晦涩;6.过度设计;
僵化性:很难堆系统进行改动;改一处会导致依赖关系模块中的连锁改动,设计僵化

脆弱性:对系统的改动,会引起其他无关的许多地方出现问题

牢固性:很难解开系统的纠结,使之成为一些可在其它系统中重用的组件,

粘滞性:做正确的事情,比做错误的事情要困难。

不必要的复杂性:设计中包含不具有任何直接好处的基础结构,例如写了一段没用的代码

不必要的重复:设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象,进行统一。复制粘贴代码

晦涩性:难以阅读、理解代码。没有很好的表现意

代码腐化的例子:略
软件设计第一原则:
1.开/闭原则(OCP):不需要修改软件实体(类、模块、函数等),就能实现功能扩展,关键字:抽象
1.对于扩展是开放的
2.对于更改是封闭的
基于UML小练习,
改进1:

改进2:策略模式

改进3:适配器模式

改进4:观察者模式

软件设计第二原则:依赖倒置原则(DIP)
DIP:Dependency Inversion Principle
1.高层模块不能依赖低层模块,而是大家都依赖于抽象;
2.抽象不能依赖实现,而是实现依赖抽象
违反案例:

正常案例:

框架核心:

OOD 原则三:Listov替换原则(LSP)
简而言之: 子类型必须能够替换调他们的基类型
违反案例1:过多的if else

违反案例2:

正方形IS-A长方形吗?


IS-A关系是关于行为的,(实用场景),分析场景,判断IS-A使用是否合适。

引用问题:
子类override父类的方法后,想要修改抛出的异常,那么子类方法抛出的异常应该是父类方法抛出异常类的子类还是父类?
答:子类,因为按照LSP原则来看,子类”契约“不能比父类更”严格“,只能更宽松

违反LSP原则的代码,如何修改:
将共性代码抽离到基类中去
方法组合
可能违反LSP的征兆:
1.派生类的退化函数
2.派生类中抛出基类不会产生的异常

OOD原则四 : 单一职责原则(SRP)
SRP - Single Responsibiliy Principle
1.又称为”内聚性原则“,意为:一个模块的组成元素之间的功能相关性
2.将它与引起一个模块发生变化的操作关联,就形成了:一个类只能有一个引起他变化的原因
什么是职责?
一个职责是一个变化原因。
违反案例:



区分类的方法:分清职责

OOD原则五:接口分离原则(ISP)
1.不应该强迫客户程序依赖他们不需要的方法

胖接口案例讲解:

继承后,父类发生变化,Door就跟着受影响

改进方式:
1.适配器组合

2.多重继承

作业:接口隔离 Cache 类的设计

推荐书籍:《敏捷软件开发》

评论