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