怎么开网站,企业网站必备模块,wordpress菜单显示选项,优化推广方案1 关于设计模式
设计模式是什么#xff1f;个人理解#xff0c;其是软件开发中对一些通用问题整理的解决方案#xff0c;是经过经验总结所提炼的相对较为抽象的#xff0c;有一定适应性和变化性的“套路”。这里借用了“套路”这个不太好听的词#xff0c;但目的却是为了…1 关于设计模式
设计模式是什么个人理解其是软件开发中对一些通用问题整理的解决方案是经过经验总结所提炼的相对较为抽象的有一定适应性和变化性的“套路”。这里借用了“套路”这个不太好听的词但目的却是为了避坑。
关于设计模式经典的著作就是称为GOF的四人组所编写的那本Design patterns。多说两句关于设计模式个人有两点看法其一现代软件系统设计的越来越庞大复杂能够用简单的概念和方法解决问题反而是一种本领。这样一来软件的可维护性和健壮性将得到大大提升。如果有一天人工智能发展到绝顶聪明的程度不再需要人类编写维护软件时这一条观点就可以过时了但是现在还远远未到这个要求所以这一点还是要奉为圭臬。很多一线大佬都指出哪些复杂无比充斥不必要技巧的代码往往是对问题没有彻底理解清楚的产物对于这一点我是比较认可的。回到设计模式我觉得书中所体现的思想是值得学习的而具体各个模式的方法反而是要避免复杂化的。形式大于内容并不可取容易走向花架子方向偏离本质。反倒是有一些简单的介绍这些模式的书籍倒是比较推荐的像大话设计模式。其二当你学完所有的模式后不知道是否有这样一种感觉就是所有模式其实都是围绕着一个中心点在反复咀嚼这个中心点就是抽象。如果一个人把抽象掌握的熟透并在实际开发中加以应用回过头来你会发现他或多或少都是采用了某个设计模式或者说有某个模式的影子。可能并不完全一致但是其却有相通的妙处。
运用抽象的好处我在发布的其他博文里也有提及并加以反复强调这里再提提。抽象最大的好处就是本质不变特性。这一特性应用于软件开发特别适合应对变化。因为变化是软件开发的最大绊脚石。有了这一法宝当然前提是拿捏的好运用的秒就可以做到以不变应万变。关于抽象这里就说这么多不再展开。
博主第一次接触到大量运用设计模式的代码是Android的源码。对于初学者而言是不错的学习资料。在了解了设计模式的概念后遇到实际的代码要多想想为啥采用这种模式有什么好处。多思考才能有收获。 2 设计模式本身的概念
设计模式被分为三大类型分别是创建型、结构型以及行为型。我是比较讨厌这种分类的因为官方的分类方法和我自己的理解总感觉有出入这样在拿出来要用的时候就比较痛苦需要一些背诵记忆的能力。这种感觉跟中学学政治一样不知道是不是因为自己语文太差对一些文字的含义理解不到位而导致了这种错觉。既然官方按这种方式分类了记住就好实在觉得别扭就找一些比较容易理解的能够往官方分类方向靠的例子来辅助记忆。 具体的分类如下
创建型包括工厂模式、抽象工厂模式、单例模式、构建者模式、原型模式
结构型模式包括桥接模式、适配器模式、组合模式、代理模式、享元模式、装饰模式、外观模式
行为型模式包括职责链、策略模式、迭代模式、命令模式、状态模式、观察者模式、解释器模式、中介模式、访问者模式、模板方法、备忘录模式 关于这些模式的具体说明这里就不再展开了网络的资料十分丰富。虽然GoF提炼了23种模式但是实际中常见的模式就那么几种没必要死扣每一种而且不用的那些时间长了也就会遗忘所以大概了解即可达到给个选择题能够分辨出来的程度即可。 3 设计模式在系统中的应用和体现
对于设计模式学以致用才是关键。能够在了解-理解-掌握-运用的链条上达到最终的自如运用才说明内化于心了。下面仍然以前述某电力系统项目为例谈谈在项目中对设计模式的运用。
首先是适配器模式。这是很常见的一种设计模式多应用于数据匹配上。在该电力系统项目中也是做数据适配这一目的但是细节上又有所不同。项目中围绕会商功能开展了诸多业务这些业务关联了诸多数据如何有效、高效管理这些数据就是设计上的一项小挑战了。比如除了常见的音频、视频数据外还有各种采集的电压、电流、温度、定位、图像、短信等各种业务数据。为了有效的管理这些数据系统设计时对数据进行了抽象将其分解为两类数据一种是流类数据一种是包类数据是不是有点类似TCP和UDP。确实单从抽象概念上讲是挺像的。每一类数据都有一个源与其关联而所有的源都来自一个统一的抽象这样当某个功能或业务需要数据时就将其对接到抽象源上也就是适配到统一的适配器上而具体每一个数据源的处理又根据其不同的特点就自己独特的实现。这样既满足了抽象的统一有实现了个体的独立后续有新的业务或数据需要适配时也仍然走一套统一的抽象对接流程和具体的实现范式不对整体系统的设计构成冲击又满足了变化的需求可谓一石二鸟。
从这个例子中我们可以再次感受到前面所提的模式和抽象的关系。
其次观察者模式。这也是非常非常常见的一个模式特别是应对有回调处理的一类事务时。比如像界面相关的处理通用组件的一些处理按钮响应、列表滚动选择等等大都会用到这一模式。在该电力系统项目中也是大量使用了观察者模式。首先是有关数据采集的部分底层基于异步事件构建了一个统一的框架而每一类事件的数据响应就是通过观察者模式对接到界面应用的这包括了电压电流数据、GPS定位数据、电源管理数据、按键数据、WIFI事件、对讲事件等等。另外对于音视频的处理也是采用类似的方法。底层首先设计了一套管线用于完成音视频数据的采集、编码、传输、接收、解码、渲染等过程。但是在这条管线上还有许多关联业务需要处理此时观察者模式就派上用处了。比如满足特定条件时进行音视频的截取录制、混音降噪等处理通过观察者模式实现数据的分流在基本业务特性不受影响的前提下可插入丰富的定制业务功能实现主线和分支的统一管理协同工作。
第三模板方法模式。该模式的使用有点类似Android的activity抽象。在工单业务流上采用统一的任务处理模板基于抽象的任务模式定制实现独特的各种子类业务功能是不是又感受到了抽象的魔力。而且界面的功能处理也是采用了统一的生命周期模板业务界面回到前台退出前台运行退出运行都是该模式的体现。升级和文件的上传下载也采用了统一的进度模板只需要传递总量数据和当前片长即可。另外终端部分的驱动也是运用模板方法的生动体现。整个框架分为了初始化、读写、中断、去初始化等几个块这样一来将抽象和复用利用到了极点。抽象方便了复用而复用又促进了抽象很多时候抽象并不是一开始就想象出来的而是在开发过程中通过对共性的提炼总结最终自然而然的就会形成抽象的雏形。
第四状态模式。状态模式是对传统C语言中状态机的等价表示。客户端自身也是有状态的比如登录、加入会商、在线、离线等这些逻辑的处理就是状态模式发挥作用的地方。另外网络库部分也是状态模式抽象的重点。连接、断开的高效管理不仅简化了业务层面的开发也使得整个代码更加易读减少了错误提高了效率增强了可靠性一举多得。
最后还有其他一些模式的使用比如代理模式跨进程的接口代理做测试桩都是大量使用的。单例模式一个时刻一台终端保持一个客户端就用单例实现。全局统一的消息队列也用单例方便获取使用保证了异步安全性。工厂模式用于创建各种实例特别是经典的数据库实例场景通过工厂模式统一支持不同数据库产品不再为切换不同厂家数据库产品而改系统代码。 关于设计模式在实际系统中的应用就整理这么多。很多时候我们并不是刻意去选择使用哪种模式除非是一些非常常见的经典的场景有现成可用的模式模板可以顺手拿来就用而是先充分理解功能理解业务本身然后考虑各种可能和变化在这个过程中尽可能的提炼得到抽象物之后再将抽象应用于设计实现在这一整套思考并实践的过程中你会发现某些设计模式会自然而然的被应用于系统中反倒是那些刻意为之的模式往往最后给人一种别别扭扭的感觉难以重构或者问题频出。其实生活中的其他领域也是如此体现本质的设计往往更有生命力而那些流于花哨形式的设计往往得不偿失。
