架构师训练营 - 学习笔记 - 第二周
编程发展史
回顾了德国大佬莱布尼茨提出计算可执行演算规则,法国人雅卡发明可编程织布机,开始将打孔纸带用于计算机编程,和英国人Ada写出人类第一个软件程序,随后到图灵等科学家试图创造一种通用的计算机,最后开启编程新时代。
学习这门课的要点
要努力跳出技术表面去思考技术背后的规律,面向对象编程不是使用面向对象的编程语言进行编程,而是利用多态特性进行编程。
什么是面向对象编程?
1.万物皆为对象(我们关注的需要解决的问题本身皆为对象)
2.程序是对象的集合,它们通过发送消息来告知彼此所要做的
3.每个对象都有自己的由其他对象所构成的存储
4.每个对象都拥有其类型
5.某一特定类型的所有对象都可以接收同样的消息
面向对象设计的目的
1.强内聚、低耦合
2.易扩展
3.更强壮
4.可移植
5.更简单
面向对象设计的原则
1.为了达到上述设计目标,有人总结出了多种指导原则
2.“原则”是独立于编程语言的,甚至也可以用于非面向对象的编程语言中
设计模式/框架/工具
1.设计模式是用于解决某一种问题的通用的解决方案
2.用来实现某一类应用的结构性程序, 是对某一类架构方案可复用的设计与实现,用框架保证架构的落地
有臭味的程序
1.僵硬 - 不易增加、修改
2.增加一种 Button 类型,就需要对 Button 类进行修改
3.修改 Dialer,可能会影响 Button
4.脆弱 - switch case/if else语句是相当脆弱的
5.当我想修改 Send 按钮的功能时,有可能不小心破坏数字按钮
6.当这种函数很多时,我很有可能会漏掉某个函数,或其中的某个条件分支
7.不可移植
怎样设计好一个程序
OOD 原则一:开/闭原则(OCP)(面向抽象接口编程)
OCP - Open/Closed Principle
• 对于扩展是开放的(Open for extension)
• 对于更改是封闭的(Closed for modification)
• 简言之:不需要修改软件实体(类、模块、函数等),就应该能实现功能的扩展。
电话拨号案例优化
改进button第一种方法
使用多台,各种button继承button可以实现不改动源代码增加buttongon功能扩展.但是当dialer修改时需要修改button,button也不是可以移植的,仍需优化
改进button第二种方法使用策略模式
客户端应用程序不直接依赖要依赖的目标对象,而是通过定义一个策略接口.去依赖策略接口,目标依赖对象去实现策略接口,这样客户端便不会直接依赖目标对象,如果要增加功能时只需要增加策略实现类就可以了
因为适配器传过来的参数是一个int的token,Dailer变的脆弱了,所以需要在Dailer里进行 swich case,依然需要优化
改进button第三种方法使用适配器模式
通过适配器实现buttonServer接口,通过对buttonServer的接口调用转换成对适配器的接口调用,这样Dailer里就不需要写 swich case 了,这种设计不够灵活,button 只能调用一个buttonServer,button 按下时如果还有别的操作,就处理不了了
改进button第三种方法使用观察者模式
把策略接口改成listener接口,在Button里面addListener,在实现里for循环listener调用每一个listener的buttonPressed接口
依赖倒置原则(DIP)
DIP - Dependency Inversion Principle
1. 高层模块不能依赖低层模块,而是大家都依赖于抽象;(先开发接口,后实现接口)
一个接口是属于高层模块的,高层模块会根据自己的使用场景进行接口设计和抽象,service高层模块定义的一个接口,低层模块dll去实现这个高层接口是依赖倒置,倒置了开发者的层次关系
低层模块不能按照高层定义的接口进行实现,而自己可以写一个接口写一个实现供高层去调用不属于依赖倒置,在高层模块里不能直接依赖具体的低层实现类
2.抽象不能依赖实现,而是实现依赖抽象
DIP 倒置了什么?
1.模块或包的依赖关系
2.开发顺序和职责
软件的层次化
1.高层决定低层
2.高层被重用
好莱坞原则
框架调用我们的代码,我们不能调用框架代码
里氏替换原则(衡量继承是否合理的原则)
1.A类替换B类后程序代码可以正常运行,则A类是B类的子类,符合里氏替换原则
2.主要还是父类的场景子类是否都可以正常运行,能运行符合原则 ,不能运行不符合原则
3.子类的访问控制权限不能比父类严格
4. 对于违反原则的可以提取共性到父类,更好的方法是将继承改成组合,将父类变成自己的成员变量,可以调用成员变量的方法,减少不必要的继承,应该优先使用组合,然后使用继承
单一职责原则
一个类应该只有一个引起他变化的原因,如果一个类引起他变化的原因过多,这个类的职责就不是单一的。
违反职责的后果:
1.脆弱性 - 把绘图和计算功能耦合在一起,当修改其中一个时,另一个功能可能会意外受损。
2.不可移植性 - 计算几何应用只需要使用“计算面积”的功能,却不得不包含 GUI 的依赖。
接口分离原则
实现类实现两个接口,不同的应用程序可以依赖不同的接口
设计一个接口从客户的需要出发,强调不要让客户看到他们不需要的方法
评论