说框架、架构、模式、重构

有些概念,有人提到,一并说说吧。

框架很多,各种各样的,不同的平台,不同的语言,不同的功能。

现阶段的软件项目,几乎都会用到框架,何为框架,为什么要用框架。

所谓框架,是一种看得见的软件产品,是一种半成品。既然他是产品,他应该已经在那里了,如果你愿意,你可以使用他。就像一幢施工了一半,已经有梁有柱,有楼板、简单楼梯的五层楼房,只要你愿意,你可以爬楼梯锻炼身体。而他是半成品,说明他还不完整,需要对他进行填空。而这些空将决定“成品”是什么。刚才锻炼身体的楼房按照不同的布局和装饰可以成为写字楼,或者住宅。由于软件的可复制性,抽取出大部分楼房的共性,在此基础上加以相对少量的施工即可满足市场的需要,提高了软件的生产效率,此其一。

同样由于软件的可复制性,框架代码往往是较长时间的积累与实践测试,质量较高。上面说的那个楼房我保证每层楼高都相同,且结构可以抗8级地震,只要在这个结构基础上施工,不论多少人一起施工,房子也不会出这方面的问题,不管你懂不懂工程力学。因此提高了软件的质量,降低了开发难度与风险,加强团队开发的可能性,并降低了施工人员成本。此其二。

框架有其与生俱来的限制。还是那幢楼,如果你想在这个基础上建成国家体育场,想必也是没有什么可能的,如果蛮干,把大梁卸了,可能离新闻报道就不远了。所以选择框架要合适,使用框架也要遵循当初框架设计者的思路。此其三。

关于架构,这里讲的是软件架构。那是一种思想,你看不见。也没有一一对应的产品。他是实践中总结出的一种指导如何设计软件以达到某种要求的思路。

你要盖个一层两层小房,简单,来几根好点的木料,加几车砖,就行了,砖木结构。三到四层?砖混结构。五到十五层?钢混结构。十五层到四十层?全钢结构。四十层以上?那就复杂了,请教专家去。

架构思路是比较抽象的,他指明了在某种大体的场景下的大概的方向。在框架的设计中往往始终贯穿着一种或者几种架构思想。

模式呢?那是在某一范围内某种场景下为解决某种问题而可以重复实践的方案。高层建筑,用电梯。要房间明亮,弄个落地窗。这些使得我们在遇到某种场景下,不需要花大力气去思考,就可以较完美解决的方案。就像数学公式。

在框架内部,结构可能会十分复杂,中间也夹杂着太多的问题需要解决,所以在框架设计中,往往非常多的应用到模式。

事情很复杂,在开工之前没有必要将所有的细节全部考虑清楚。在施工过程中发现当前的结构中有一些不合理的地方。盖楼前没考虑用哪种门,先盖了再说吧,等开始装门的时候,发现每个房间的门都自己做,费工时,成本高,效果又不好。于是有个前辈说:不用这么麻烦,打个电话给XXX工厂,让他们提供某个系列的各种规格的门,送货上门,包安装还有保修,省心了。唔,重构就是在设计过程中对于软件中出现的臭味进行消除,使之符合某种设计模式的过程。

时间: 2024-11-18 03:17:17

说框架、架构、模式、重构的相关文章

.NET框架设计(高级框架架构模式)—钝化程序、逻辑冻结、冻结程序的延续、瞬间转移

阅读目录: 1.开篇介绍 2.程序书签(代码书签机制) 2.1ProgramBookmark 实现(使用委托来锚点代码书签) 2.2ProgramBookmarkManager书签管理器(对象化书签集合的处理,IEnumerable<T>书签管理)  3.可恢复语句组件(将语句对象化) 3.1可恢复语句组件管理器(将可恢复语句视为普通的对象成员,IEnumerable<T>可恢复语句组件) 3.2可恢复语句组件运行时(Program CLR(简介)) 3.3可恢复语句逻辑配置(规则

iOS 开发中的 Flux 架构模式

本文讲的是iOS 开发中的 Flux 架构模式, 在半年前,我开始在 PlanGrid iOS 应用程序中采用 Flux 架构(开发).这篇文章将会讨论我们从传统的 MVC 转换到Flux的动机,同时分享我们目前积累到的经验. 我尝试通过讨论代码来描述我们大部分的 Flux 实现, 它用于我们今天的产品中. 如果你只对综合结果感兴趣, 请跳过这篇文章的中间部分. 为什么从 MVC 转移 为了引入我们的决定, 我想要先谈一谈 PlanGrid 这个应用遇到的一些挑战.一些问题仅针对企业级应用程序,

数据源架构模式 表入口 行入口 活动记录 数据映射器

数据源架构模式 - 表入口模式 表入口模式充当数据库表访问入口的对象,一个实例处理表中的所有行. 可以理解为对之前分散在各个页面的sql语句进行封装,一张表就是一个对象,该对象处理所有与该表有关的业务逻辑,很好的提高了代码的复用性. 现在想起来,当初刚毕业那会儿,经常使用表入口模式. 具体的实现方式参见代码: database.php <?php    class Database{       //只是为了演示,通常情况下数据库的配置是会单独写在配置文件中的       private sta

MVC架构模式与利用JAVABEAN分页

众所周知MVC不是设计模式,是一个比设计模式更大一点的模式,称作设计模式不合理,MVC模式应该叫架构模式,MVC里面用了许多小的模式,例如策略模式,组合模式,聚集模式,可以用到的模式有十几种之多,而设计模式里也就27种,MVC很重要,现在流行的STRUTS框架也是类似的实现,建议大家有时间可以研究下STRUTS,现在很多公司都开始使用这个框架来做大型的企业系统开发,STRUTS是APACHE的一个开源项目,所有资料都可以从APACHE网站得到.当然目前国内也有翻译了一些STRUTS文章,不过大都

asp.net 浅谈MVC 架构模式(上)

最近总听一些人在讨论MVC.MVP.MVVM各种架构模式之间的关系及提升之处,自己也想写一些关于这3种模式相关的东西,同时来比较一下它们的区别.在日常开发中,我们有很多机会接触到MVC.MVP,MVVM也许是搞WPF及Silverlight的同事接触的多一些,但可以肯定的是无论采用哪种模式都是为了解决一些实际的问题.这3种模式是有一定的演化顺序的.大家都知道我们最先接触的是MVC然后是MVP接着最近几年的MVVM.它们分别解决的问题不同,使用的场景也不同,可以说各有各的用处各有各的好处.那么怎么

微服务:真正的架构模式

本文讲的是微服务:真正的架构模式[编者的话]本文来自Medium,通过比较CRUD app和数据流app两种应用类型的微服务化探索来向听众介绍微服务. 简介 微服务的神秘和背后的知识令我着迷.微服务作为概念,它属于现代最有趣的架构之一.微服务应用广泛,涉及不同的使用场景.但也有很多地方模糊不清,难以定论. 人们在讨论微服务时,我会努力理解他们的真实意图.尽管在上一次演讲中我分享了对微服务的认识,但我很清楚其它公司和我们使用的架构是不一样的.最近我询问了一位同行,了解到他们部署微服务的方式(和我)

面向移动互联网的需求管理与应用架构模式研究

随着3G/4G移动通信技术和云计算.大数据等信息技术的不断发展和成熟,逐渐形成了"移动终端+无线通信网络+平台+应用"的价值承载体系结构,人们也逐渐习惯了借助移动终端完成互联网服务的消费,标志着人类社会已经步入移动互联网时代. 针对移动互联网时代对于服务提供商的要求,电信运营商需要在需求管理和应用开发模式方面进行创新.电信运营商传统的需求管理模式往往是业务部门在市场经营中形成对于业务支撑系统的需求,然后有软件开发商进行需求调研并开发实施.这种需求管理和应用开发模式最大的问题就是开发周期

iOS - MVP 架构模式

1.MVP 从字面意思来理解,MVP 即 Modal View Presenter(模型 视图 协调器),MVP 实现了 Cocoa 的 MVC 的愿景.MVP 的协调器 Presenter 并没有对 ViewController 的生命周期做任何改变,因此 View 可以很容易的被模拟出来.在 Presenter 中根本没有和布局有关的代码,但是它却负责更新 View 的数据和状态.MVC 和 MVP 的区别就是,在 MVP 中 M 和 V 没有直接通信. MVP 是第一个如何协调整合三个实际

.NET面向上下文、AOP架构模式(概述)

1. 上下文概述 上下文:其实就是一个逻辑上的业务.功能区域.在这个逻辑区域里可以有效的进行管理,算是一种制度的约束,也可以理解为某种范围类的数据共享. 其实在很多应用框架中到处可以看见上下文的概念,包括.NET本身的设计就建立在这种思想上的.实例化的对象默认存在于系统中的默认上下文中,我们可以构建自己的上下文将对象在运行时进行合理的管理. 在ASP.NET框架中比较经典的就是HttpContext上下文对象.所有的运行时对象都会逻辑归属到HttpContext上下文中来,如:我们可以使用Req

.NET面向上下文、AOP架构模式(实现)

1.上下文Context.面向切面编程AOP模型分析 在本人的.NET面向上下文.AOP架构模式(概述)一文中,我们大概了解了上下文如何辅助对象在运行时的管理.在很多时候我们急需在运行时能把对象控制在一定的逻辑范围内,在必要的时候能让他们体现出集中化的概念,如人群.车辆.动物等等.而Context与AOP有着密切的联系,Context表示逻辑抽象的范围而AOP描述了在这个逻辑范围内如何进行控制.其实这两者都是设计模式外的设计模式,与具体的技术实现无关.[王清培版权所有,转载请给出署名] 那么Co