设计模式再探——宏观篇

一、背景介绍

最近在做产品技术建模的过程中，一些地方刻意用到了设计模式，而一些地方也用到了但是并不是很明确。

于是乎就带着这个疑惑来再探设计模式的宏观；也查阅了自己的博文：

• 1.14年有宏观(第一层看山是山，知道了有设计模式以及七大原则这个东西)、
• 2.21年有宏观(第二层看山不是山，看着那些模式和原则结合自己曾经的项目经历，让自己逐渐模糊了，设计模式到底有什么用?为什么好多地方都说他伟大？)
• 3.现在有宏观(第三层不是山也是山，揭开通过设计模式训练抽象思想的面纱)

题外话：数字化世界的好处在这里充分的体现出来了，能够让我们跨越年份进行复盘回顾的时候依据很具体明确；这是一个未来趋势，你愿意在数字世界充分留有自己的足迹嘛？

二、思路&方案

• 1.宏观介绍
• 2.目的与意义
• 3.七大原则的定义与边界
• 4.思路由来

三、过程

1.宏观介绍

百度百科定义：软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。

扩展(设计模式与下面两个概念的关系是？)：
面向对象(抽象基础；封装、继承、多态特征)
软件工程(可复用、可扩充、可维护)

2.目的与意义

目的：基于面向对象，实现软件工程
意义：训练抽象思想，形成封装变化、对象间松耦合、针对接口编程下意识的行为

3.七大原则的定义与边界

开闭原则：模块应对扩展开放，而对修改关闭
边界：1.扩展为增加新代码；修改是修改原来的代码(包括属性、方法、类)；

单一职责原则：就一个类而言，应该仅有一个引起它变化的原因
边界：类内的属性修改和方法调用；产生的多余一个的动机；那么该类就需要再拆分职责

里氏代换原则：如果调用的是父类的话，那么换成子类也完全可以运行
边界：保证子类继承(复用)父类的所有属性和方法都是可用的

接口隔离原则：一种角色，不多不少，不干不该干的事，该干的事都要干
边界：返回的对象只能拥有强转成父类对象的行为；涉及到一个向上强转的知识

依赖倒转原则：高层模块不应该依赖于底层模块，两个都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象
边界：任何一个业务类的定义都必须有接口或者抽象类；面向抽象类或者接口编程

迪米特法则：一个软件实体应当尽可能的少与其他实体发生相互作用
边界：降低类间耦合；一个类要协调其它类来处理事情，那么只需要协调一个类来给处理就好了

合成复用原则：少用继承，多用合成关系来实现
边界：使得继承这种强耦合的关系减弱，有明确父子关系吗？可以用组合聚合来实现嘛？

4.思路由来

定义边界，进行遍历；像洋葱一样一层一层的剥开

四、总结

• 1.面向对象不仅仅是我定义了类，实现了接口，实例化出来对象去实现了业务；还要必须让定义的类符合七大原则
• 2.一个产品的生命力，决定了起初的宏观定位，基于软件工程的定位去做技术建模
• 3.代码如人生，代码如此-抽象思想和能力(复用性多高、扩充性多强、维护性多低)，人生亦如此-感悟灵魂的升华(渡己频率、渡人频次)

五、升华

庆幸自己还可(天时)回头望、还能(地利)回头望、还在(人和)回头望；轻舟已过万重山。