一、背景介绍
最近在做产品技术建模的过程中,一些地方刻意用到了设计模式,而一些地方也用到了但是并不是很明确。
于是乎就带着这个疑惑来再探设计模式的宏观;也查阅了自己的博文:
- 1.14年有宏观(第一层看山是山,知道了有设计模式以及七大原则这个东西)、
- 2.21年有宏观(第二层看山不是山,看着那些模式和原则结合自己曾经的项目经历,让自己逐渐模糊了,设计模式到底有什么用?为什么好多地方都说他伟大?)
- 3.现在有宏观(第三层不是山也是山,揭开通过设计模式训练抽象思想的面纱)
题外话:数字化世界的好处在这里充分的体现出来了,能够让我们跨越年份进行复盘回顾的时候依据很具体明确;这是一个未来趋势,你愿意在数字世界充分留有自己的足迹嘛?
二、思路&方案
- 1.宏观介绍
- 2.目的与意义
- 3.七大原则的定义与边界
- 4.思路由来
三、过程
1.宏观介绍
百度百科定义:软件设计模式(Design pattern),又称设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
扩展(设计模式与下面两个概念的关系是?):
面向对象(抽象基础;封装、继承、多态特征)
软件工程(可复用、可扩充、可维护)
2.目的与意义
目的:基于面向对象,实现软件工程
意义:训练抽象思想,形成封装变化、对象间松耦合、针对接口编程下意识的行为
3.七大原则的定义与边界
开闭原则:模块应对扩展开放,而对修改关闭
边界:1.扩展为增加新代码;修改是修改原来的代码(包括属性、方法、类);
单一职责原则:就一个类而言,应该仅有一个引起它变化的原因
边界:类内的属性修改和方法调用;产生的多余一个的动机;那么该类就需要再拆分职责
里氏代换原则:如果调用的是父类的话,那么换成子类也完全可以运行
边界:保证子类继承(复用)父类的所有属性和方法都是可用的
接口隔离原则:一种角色,不多不少,不干不该干的事,该干的事都要干
边界:返回的对象只能拥有强转成父类对象的行为;涉及到一个向上强转的知识
依赖倒转原则:高层模块不应该依赖于底层模块,两个都应该依赖抽象;抽象不应该依赖细节,细节应该依赖抽象
边界:任何一个业务类的定义都必须有接口或者抽象类;面向抽象类或者接口编程
迪米特法则:一个软件实体应当尽可能的少与其他实体发生相互作用
边界:降低类间耦合;一个类要协调其它类来处理事情,那么只需要协调一个类来给处理就好了
合成复用原则:少用继承,多用合成关系来实现
边界:使得继承这种强耦合的关系减弱,有明确父子关系吗?可以用组合聚合来实现嘛?
4.思路由来
定义边界,进行遍历;像洋葱一样一层一层的剥开
四、总结
- 1.面向对象不仅仅是我定义了类,实现了接口,实例化出来对象去实现了业务;还要必须让定义的类符合七大原则
- 2.一个产品的生命力,决定了起初的宏观定位,基于软件工程的定位去做技术建模
- 3.代码如人生,代码如此-抽象思想和能力(复用性多高、扩充性多强、维护性多低),人生亦如此-感悟灵魂的升华(渡己频率、渡人频次)
五、升华
庆幸自己还可(天时)回头望、还能(地利)回头望、还在(人和)回头望;轻舟已过万重山。