什么是架构
软件体系结构通常被称为架构指可以预制和可重构的软件框架结构架构尚处在发展期对于其定义学术界尚未形成一个统一的意见而不同角度的视点也会造成软件体系结构的不同理解以下是一些主流的标准观点
ANSI/IEEE 软件工程标准词汇对于体系结构定义是体系架构是以构件构件之间的关系构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)
Mary Shaw和David Garlan认为软件体系结构是软件设计过程中超越计算中的算法设计和数据结构设计的一个层次体系结构问题包括各个方面的组织和全局控制结构通信协议同步数据存储给设计元素分配特定功能设计元素的组织规模和性能在各设计方案之间进行选择Garlan & Shaw模型[]的基本思想是软件体系结构={构件(component)连接件(connector)约束(constrain)}．其中构件可以是一组代码如程序的模块也可以是一个独立的程序如数据库服务器连接件可以是过程调用管道远程过程调用(RPC)等用于表示构件之间的相互作用约束一般为对象连接时的规则或指明构件连接的形式和条件例如上层构件可要求下层构件的服务反之不行两对象不得递规地发送消息代码复制迁移的一致性约束什么条件下此种连接无效等
关于架构的定义还有很多其他观点比如Bass定义Booch & Rumbaugh &Jacobson定义Perry & Wolf模型[]Boehm模型等等虽然各种定义关键架构的角度不同研究对象也略有侧重但其核心的内容都是软件系统的结构其中以Garlan & Shaw模型为代表强调了体系结构的基本要素是构件连接件及其约束（或者连接语义）这些定义大部分是从构造的角度来甚至软件体系结构而IEEE的定义不仅强调了系统的基本组成同时强调了体系结构的环境即和外界的交互
什么是模式
模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出应用于建筑领域八十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件领域Christopher Alexander将模式分为三个部分首先是周境（Context也可以称着上下文）指模式在何种状况下发生作用其二是动机（System of Forces）意指问题或预期的目标其三是解决方案（Solution）指平衡各动机或解决所阐述问题的一个构造或配置（Configuration）他提出模式是表示周境动机解决方案三个方面关系的一个规则每个模式描述了一个在某种周境下不断重复发生的问题以及该问题解决方案的核心所在模式即是一个事物（thing）又是一个过程(process)不仅描述该事物本身而且提出了通过怎样的过程来产生该事物这一定义已被软件界广为接受
软件模式的应用对软件开发产生了重大的作用主要表现在
软件模式是人们在长期的设计软件管理组织软件开发等实践中大量经验的提炼和抽象是复用软件设计方法过程管理经验的有力工具模式类似于拳击中的组合拳它提供了一系列软件开发中的思维套路如通过模式的使用有利于在复杂的系统中产生简洁精巧的设计
软件模式为我们提供了一套简洁通用的设计管理组织方面的词汇同时模式也为我们提供了一个描述抽象事物的规范标准可大大促进软件开发过程中人与人之间的交流而软件开发中的交流是至关重要的软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接收它的人
架构和模式的关系
因为架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及可是很多人容易混淆这两个术语而对此学术界也没有一个非常统一的定义
架构和模式应该是一个属于相互涵盖的过程但是总体来说Architecture更加关注的是所谓的HighLevel Design而模式关注的重点在于通过经验提取的准则或指导方案在设计中的应用因此在不同层面考虑问题的时候就形成了不同问题域上的Pattern模式的目标是把共通问题中的不变部分和变化部分分离出来不变的部分就构成了模式因此模式是一个经验提取的准则并且在一次一次的实践中得到验证在不同的层次有不同的模式小到语言实现(如Singleton)大到架构在不同的层面上模式提供不同层面的指导根据处理问题的粒度不同从高到低模式分为个层次架构模式(Architectural Pattern)设计模式(Design Pattern)实现模式(Implementation Pattern)架构模式是模式中的最高层次描述软件系统里的基本的结构组织或纲要通常提供一组事先定义好的子系统指定它们的责任并给出把它们组织在一起的法则和指南比如用户和文件系统安全策略模型N层结构组件对象服务等我们熟知的MVC结构也属于架构模式的层次一个架构模式常常可以分解成很多个设计模式的联合使用设计模式是模式中的第二层次用来处理程序设计中反复出现的问题例如[GOF][]总结的个基本设计模式——Factory Pattern Observer Pattern等等实现模式是最低也是最具体的层次处理具体到编程语言的问题比如类名变量名函数名的命名规则异常处理的规则等等
相对于系统分析或者设计模式来说体系结构从更高的层面去考虑问题所以关注的问题就体现在不变因素上比如系统部署中更加关心应用程序的分层分级设计而在这个基础之上提出的部署方案才是架构考虑的重点体系结构关心应用程序模式更加体现在通过技术去解决这些业务差异带来的影响关心是否是分布式应用程序关心系统分层是如何设计也关心性能和安全因此在这样的情况之下会考虑集群负载平衡故障迁移等等一系列技术
希望通过定义的方式来区分架构和模式是不太可能的因为本来就是交互交叉和提供服务的它实际上是架构模式而不是设计模式在大部份情况下表现为下面几个设计模式之一Strategy模式Mediator模式Composite模式Observer模式对于熟悉架构设计的系统架构师而言似乎可以用如下来解释架构和模式之间的关系架构是HightLevel Design着眼于不同业务中共性的解决方案而模式是General Principle(通用原理)
企业解决方案的构建模式
企业级业务解决方案是公司实现其业务的赌注它们通常极其复杂而且性能必须不负众望它们不仅必须具有高可用性和伸缩性以应对不可预知的使用而且还必须具有适应性和预见性以适应快速变化的业务要求最佳解决方案是那些由一组更小的简单的能够可靠且有效地解决简单问题的机制组成的解决方案在构建更大更复杂的系统过程中将这些简单的机制组合在一起从而形成更大的系统对这些简单机制的认识来之不易它通常存在于有经验的开发人员和体系结构设计者的头脑中并且是他们潜意识中自然带到项目中的重要知识
模式对于开发人员和体系结构设计者非常有用因为它们
记录能够正常工作的简单机制
为开发人员和体系结构设计者提供通用的词汇和分类法
允许以模式组合的方式简明扼要地描述方案
允许重复使用体系结构设计和实现决策
模式可以记录简单机制
模式描述给定上下文中反复出现的问题并基于一组指导性影响因素来建议解决方案解决方案通常是一种简单的机制是为了解决模式中所标示出的问题而一起工作的两个或多个类对象服务进程线程组件或节点之间的协作
您正在构建一个报价应用程序其中有一个类负责管理系统中的所有报价很重要的一点是所有报价都应与该类的一个（而且只与一个）实例进行交互如何构造您的设计以便从该应用程序中只能访问该类的一个实例？
解决该问题最简单的方案就是创建一个具有私用构造函数的QuoteManager类以便任何其他类都不能实例化它此类包含QuoteManager的一个静态实例并使用名为GetInstance()的静态方法返回此代码大体如下所示
public class QuoteManager
{
//注意仅适用于单线程应用程序
private static QuoteManager _Instance = null;
private QuoteManager() {}
public static QuoteManager GetInstance()
{
if (_Instance==null)
{
_Instance = new QuoteManager ();
}
return _Instance;
}
// QuoteManager提供的函数
}
您可能已经像其他许多开发人员那样通过类似的方式解决过类似的问题实际上注意反复出现的问题并寻求解决方案的模式作者已经屡次发现了这种实现提取出了通用解决方案并将这种问题解决方案对称为Singleton模式[GOF]
问题解决方案对模式
图 简化的Singleton模式
通过将图中简化的模式示例与QuoteManager源代码进行比较阐明了模式（通用问题解决方案对）和模式应用程序（针对非常具体的问题的具体解决方案）之间的区别模式级别的解决方案是多个类之间简单但极其顺畅的协作模式中的通用协作专门适用于QuoteManager类提供了用来控制报价应用程序中实例化的机制显然您可以稍微修改一下某种模式以满足局部的特定要求所以同一种模式可以应用于无数个应用程序
所编写的模式提供了一种记录简单且经过证实的机制的有效方法模式是以特定格式编写的这一点对于装载复杂思想的容器非常有用这些模式在被记载和起名之前就早已存在于开发人员的大脑及其代码中
