设计模式再探——宏观篇

目录

一、背景介绍

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

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

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

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

二、思路&方案

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

三、过程

1.宏观介绍

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

扩展(设计模式与下面两个概念的关系是?):

面向对象(抽象基础;封装、继承、多态特征)

软件工程(可复用、可扩充、可维护)

2.目的与意义

目的:基于面向对象,实现软件工程

意义:训练抽象思想,形成封装变化、对象间松耦合、针对接口编程下意识的行为

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

开闭原则:模块应对扩展开放,而对修改关闭

边界:1.扩展为增加新代码;修改是修改原来的代码(包括属性、方法、类);

单一职责原则:就一个类而言,应该仅有一个引起它变化的原因

边界:类内的属性修改和方法调用;产生的多余一个的动机;那么该类就需要再拆分职责

里氏代换原则:如果调用的是父类的话,那么换成子类也完全可以运行

边界:保证子类继承(复用)父类的所有属性和方法都是可用的

接口隔离原则:一种角色,不多不少,不干不该干的事,该干的事都要干

边界:返回的对象只能拥有强转成父类对象的行为;涉及到一个向上强转的知识

依赖倒转原则:高层模块不应该依赖于底层模块,两个都应该依赖抽象;抽象不应该依赖细节,细节应该依赖抽象

边界:任何一个业务类的定义都必须有接口或者抽象类;面向抽象类或者接口编程

迪米特法则:一个软件实体应当尽可能的少与其他实体发生相互作用

边界:降低类间耦合;一个类要协调其它类来处理事情,那么只需要协调一个类来给处理就好了

合成复用原则:少用继承,多用合成关系来实现

边界:使得继承这种强耦合的关系减弱,有明确父子关系吗?可以用组合聚合来实现嘛?

4.思路由来

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

四、总结

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

五、升华

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

相关推荐
程序员与背包客_CoderZ3 小时前
C++设计模式——Abstract Factory Pattern抽象工厂模式
c语言·开发语言·c++·设计模式·抽象工厂模式
zzzhpzhpzzz3 小时前
设计模式——组合实体模式
设计模式
zzzhpzhpzzz6 小时前
设计模式——前端控制器模式
设计模式
forestsea7 小时前
【Java 解释器模式】实现高扩展性的医学专家诊断规则引擎
java·人工智能·设计模式·解释器模式
小白不太白9509 小时前
设计模式之 命令模式
设计模式·命令模式
吃汉堡吃到饱9 小时前
【创建型设计模式】单例模式
单例模式·设计模式
小白不太白9509 小时前
设计模式之 备忘录模式
服务器·设计模式·备忘录模式
zzzhpzhpzzz9 小时前
设计模式——策略模式
设计模式·策略模式
入门到跑路9 小时前
【君正T31开发记录】8.了解rtsp协议及设计模式
网络协议·设计模式
小白不太白9509 小时前
设计模式之 解释器模式
java·设计模式·解释器模式