浅谈解耦的意义---我们一直追求解耦,却不知道她哪里好

谈到解耦,就要提到设计模式,设计模式来源于分析模式,设计模式是分析模式的具体现话。
              举个例子,我们购买一个大件,像冰箱。

从客观的角度分析,这种东西不是我们直接拿走的,那么我们简化这个流程就是:你选择冰箱,给钱,然后营业员给你生成订单,送货人发货。如果说我们把选择冰箱,下单付款,送货期间作为粉色的时间,然后,我中间牵扯到的营业员,送货人,客户这类的参与者作为绿色,最后中间的权限例如业务员收钱的时候,从数据考虑,他是操作财务表的权限,订单是操作订单表的权限,这部分权限作为黄色,在领域模型中,在客观世界中是绿色赋予了黄色在粉色期间执行操作。客观总结起来就是指定人,拥有指定权限,做指定的操作

从三层的角度分析,我们是有数据表的,用户表,订单表,送货表等等,在数据层和业务层到底分离的是什么,还是这个购物的例子,打个不恰当的比方:业务员收钱,为其生成订单,实际上就是在操作数据,那么数据层拿走了这部分的工作。剩下的工作是,业务员哪儿来的收钱和操作财务权限?业务员怎么知道是谁要购买(谁是参与者)?这些就交给了逻辑层

将不同的职责封装到不同的类或者模块中,不正是面向对象的基本原则之一吗(单一职责原则)。但我们使用抽象工厂的设计模式时,降低了数据层和逻辑层之间的依赖关系,创建对象依赖于工厂类和一套抽象接口依赖倒置的核心思想就是抽象上层模块调用接口,下层模块实现接口。

说到这里是解耦的过程,那么解耦的意义呢?

就像我们开发过程中一个人,从前台到后台到维护,到数据库全管,就不如分工合作,内部的联系越少,一个系统就越稳定,俗话说,多一个事不如少一事。还是用实际的来说话:业务是会变化的,但是操作数据库,终归是那些方法,业务改变的时候,我们无需改变数据层。即使需要新的数据层方法,也只是添加一个方法,无需改变业务层的旧代码。刚才我们所说的又好像是分工的好处?其实来说,三层本身就是一个解耦的架构,三层的本身也是为可扩展性而生的,只是我们还需要继续使用各种模式解耦,我们只能无限降低耦合度,但并不能根除,因为彼此失去了关联就是去了意义。开放封闭原则说道:软件实体(类,模块,方法等)应该是可扩展的,意思是软件模块的功能可以变化,但是在拓展新功能的同时,不需要修改原有代码,更不会影响到原有代码。怎么能做到开放和封闭呢?还是抽象抽象的东西是稳定的,通常不需要修改,抽象的东西可以具体化为不同的实例,实现扩展。

中国梦就是个很好的面向对象设计。

中国梦可拓展:它可以拓展为农民的中国梦(拥有自己的土地),商人的中国梦(生意兴隆等),运动员的中国梦(成为冠军)

中国梦很稳定:虽然梦想千差万别,但最终都可以归于不变的中国梦。梦想的基类永不变。

时间: 2024-07-31 20:33:06

浅谈解耦的意义---我们一直追求解耦,却不知道她哪里好的相关文章

浅谈测试的意义和方法

背景: 本人曾干过1年多测试系统工程师,在此期间思考了测试的意义和方法,故记下来 关于测试工作的设想工作性质的认识, 工作职责是QC, 工作意义: 对于产品质量提升的意义: 1.1质量:在研发后,由测试人员进行独立的从模块到整机的测试,保证产品质量.和行业领先的竞争对手做比较,达到甚至超过他们的产品质量.通过模块测试保证,模块测试将扩展到IC芯片信号测试 1.2性能:首先满足设计(芯片和整机方案)的性能指标,其次与行业领先的竞争对手进行性能比较,为最终的性能提升提供规范准确的报告. 2工作内容

浅谈模质数意义下的乘法逆元

原文链接(更好的阅读体验) 参考文章www.luogu.org/blog/zyxxs/post-xiao-yi-jiang-tan-qian-tan-sheng-fa-ni-yuan 什么是乘法逆元 若整数\(b,m\)互质,并且\(b|a\),若存在一个整数\(x\),使得\(a / b \equiv a \ast x (mod \text{ } m)\),称\(x\)为 \(b\)的模\(m\)乘法逆元. 乘法逆元的用处 有时候,我们需要求\(a/b \text{ } mod \text{

张小龙浅谈微信公众平台的意义

腾讯高级副总裁张小龙表示:微信公众平台,就是在移动互联网时代,让企业和个人以更简捷的形式提供服务给有需要的人. 张小龙浅谈微信公众平台的意义,布布扣,bubuko.com

浅谈加速因子在策略中的意义

他站链接:浅谈加速因子在策略中的意义 NO:01没有完美的交易系统,但是却有完美的交易哲学.交易哲学.交易策略和资金管理三者缺一不可,才能构成正期望的交易系统.投机依赖价格的移动获得盈利(低买高卖或高买更高卖).在上升或下降趋势中,价格虽然在整体上朝着一个方向移动,但中间也会有短暂的反方向移动.而在横盘过程中,价格的移动方向则显得相对"随机"一些. NO:02关于价格的移动,可以类比物理学中的运动.其中包括:位移距离.时间.速度等.价格的位移相对于时间的比率就是价格的速度.除了速度之外

浅谈HTML5单页面架构(二)——backbone + requirejs + zepto + underscore

本文转载自:http://www.cnblogs.com/kenkofox/p/4648472.html 上一篇<浅谈HTML5单页面架构(一)——requirejs + angular + angular-route>探讨了angular+requirejs的一个简单架构,这一篇继续来看看backbone如何跟requirejs结合. 相同地,项目架构好与坏不是说用了多少牛逼的框架,而是怎么合理利用框架,让项目开发更流畅,代码更容易管理.那么带着这个目的,我们来继续探讨backbone. 首

浅谈HTML5单页面架构(一)——requirejs + angular + angular-route

本文转载自:http://www.cnblogs.com/kenkofox/p/4643760.html 心血来潮,打算结合实际开发的经验,浅谈一下HTML5单页面App或网页的架构. 众所周知,现在移动Webapp越来越多,例如天猫.京东.国美这些都是很好的例子.而在Webapp中,又要数单页面架构体验最好,更像原生app.简单来说,单页面App不需要频繁切换网页,可以局部刷新,整个加载流畅度会好很多. 废话就不多说了,直接到正题吧,浅谈一下我自己理解的几种单页面架构: 1.requirejs

浅谈移动前端的最佳实践(转)

前言 这几天,第三轮全站优化结束,测试项目在2G首屏载入速度取得了一些优化成绩,对比下来有10s左右的差距: 这次优化工作结束后,已经是第三次大规模折腾公司框架了,这里将一些自己知道的移动端的建议提出来分享下,希望对各位有用 文中有误请您提出,以免误人自误 技术选型 单页or多页 spa(single page application)也就是我们常常说的web应用程序webapp,被认为是业内的发展趋势,主要有两个优点: ① 用户体验好 ② 可以更好的降低服务器压力 但是单页有几个致命的缺点:

管理从砖瓦进化为人——浅谈传统软件工程到敏捷软件开发之变革

管理从砖瓦进化为人 --浅谈传统软件工程到敏捷软件开发之变革 前言 如果把软件开发过程比作修筑一座建筑的话,传统的软件工程方法对人的管理就像是把人化作一砖一瓦,秩序地堆砌,一层一层构建起摩天大厦. 显然地,人是不同于砖瓦那样的死物的.人作为一种复杂的动物,软件开发者会有喜怒哀乐,枯燥重复的工作内容会使他们提不起兴趣而缺乏激情:客户想法会随变动的现实而一天天有所转变,软件需求很难保持一成不变:开发者与测试者对于项目的认识会存在差异,而差异将导致效率的降低--因而传统的有些"反人类天性"的

单元测试之覆盖率浅谈

一.什么是代码覆盖率 代码覆盖是软件测试中的一种度量,描述程式中源代码被测试的比例和程度,所得比例称为代码覆盖率.一般我们用工具做的代码覆盖率的计算方法是: 代码覆盖率 = 被测代码行数 / 参测代码总行数 * 100% 二.度量方式 代码覆盖程度的度量方式是有很多种的,这里介绍一下最常用的几种: 1. 语句覆盖/行覆盖(StatementCoverage) 这是一种较为常用且具有代表性的指标,度量的是被测代码中所有语句是否被执行到. 2.判定覆盖(DecisionCoverage) 度量程序中