架构设计中的方法学

架构设计中的方法学软件设计模式来源于ChristopherAlexander的建筑学模式和对象运动。根据Alexander的观点，模式就是一个对于特定的系统的通用解决方案本身的重复。对象运动关注于将现实世界模化为软件内部的关系。基于这两个原因，软件设计模式对于真实世界的物体而言同样应当是可以重复的。这篇文章呈现了现实的世界中的非软件的模式实例，这些模式来源于《设计模式-可复用面向对象软件的基础》（DesignPatterns-ElementsofReusableObject-OrientedSoftware）[13]一书。这篇文章也举例讨论了模式语言对非软件的表现力和设计模式的练习。在软件行业中，模式支持者的团体正在扩大。模式发展的起源可以在建筑师ChristopherAlexander的著作中找到，他认为模式是世界上特定系统的通用解决方案。他描述的模式可以在日常的建筑物中观察到。《模式语言》（APatternLanguage）中的每个模式都包含了一张该模式原始范例的图片。虽然物质是主流世界的观点，而模式为软件世界所信奉，模式也有其体现事物发展的根源。不幸的是软件设计模式的例子不象Alexander模式那么丰富，因为软件设计表现的是精致的构思而不是那些最初产生的想法。当今大多数软件的专有性限制了我们接触一流设计的机会。根据Alexander的说法，现实世界中模式总是重复自己，因为在一个特定的环境下，它们总是很好地适应现有的环境因素。在软件中，要么现实世界的问题被完全地模式化，要么现实世界的物体被转换成为硬件和软件，用来产生现实世界的结果。既然软件设计模式根源于Alexander的样式和对象，那么在现实世界中找到软件设计模式也是很正常的。这并不是说软件设计模式是现实世界事物的必然模型，而是说在契合的对象之间相互影响的关系可以在现实世界和软件对象中同样地观察到。为了验证这个假设，我们将为每一种设计模式找出一个现实世界的例子来。创建型模式作者（指《设计模式》的作者-译注，下同）总结了五种创建型模式。创建型模式的例子可以在制造业，快餐，生物和行政机构中找到。抽象工厂（AbstractFactory）举例抽象工厂的目的是要提供一个创建一系列相关或相互依赖对象的接口，而不需要指定它们具体的类。这种模式可以在日本汽车制造厂所使用的金属冲压设备中找到。这种冲压设备可以制造汽车车身部件。同样的机械用于冲压不同的车型的右边车门、左边车门、右前挡泥板、左前挡泥板和引擎罩等等。通过使用转轮来改变冲压盘，这个机械产生的具体类可以在三分钟内改变。图1：抽象工厂的冲压例子生成器（Builder）举例生成器模式将复杂对象的构建与对象的表现分离开来，这样使得同样的构建过程可以创建出不同的表现。这种模式用于快餐店制作儿童餐。典型的儿童餐包括一个主食，一个辅食，一杯饮料和一个玩具（例如汉堡、炸鸡、可乐和玩具车）。这些在不同的儿童餐中可以是不同的，但是组合成儿童餐的过程是相同的。无论顾客点的是汉堡，三名治还是鸡肉，过程都是一样的。柜台的员工直接把主食，辅食和玩具放在一起。这些是放在一个袋子中的。饮料被倒入杯中，放在袋子外边。这些过程在相互竞争的餐馆中是同样的。图2：使用儿童餐作为例子的生成器模式的对象作用表工厂方法（FactoryMethod）工厂方法定义一个用于创建对象的接口，但是让子类决定实例化哪个类。压注成型演示了这种模式。塑料玩具制造商加工塑料粉，将塑料注入到希望形状的模具中。玩具的类别（车，人物等等）是由模具决定的。图3：使用注入成型为例子的工厂方法的对象图原型（Prototype）举例原型模式使用原型实例指定创建对象的种类。新产品的原型通常是先于全部产品建立的，这样的原型是被动的，并不参与复制它自己。一个细胞的有丝分裂，产生两个同样的细胞，是一个扮演主动角色复制自己原型的例子，这演示了原型模式。一个细胞分裂，产生两个同样基因型的细胞。换句话说，细胞克隆了自己。图4：使用细胞分裂例子的原型模式对象图单件（Singleton）举例单件模式确保一个类仅有一个实例，并提供一个访问它的全局访问点。单件模式是模仿单集命名的，单集的定义是每个集合仅含有一个元素。美国总统的职位是单件，美国宪法规定了总统的选举，任期以及继任的顺序。这样，在任何时刻只能由一个现任的总统。无论现任总统的身份为何，其头衔美利坚美利坚合众国总统是访问这个职位的人的一个全局的访问点。图5：使用总统例子的单件模式对象图结构性模式作者总结了七个结构型模式，这些模式的例子可以在工具、住宅配线、数学、节日传统、零售目录和银行业中找到。适配器（Adapter）举例适配器模式允许将一个类的接口转换成客户期望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。扳手提供了一个适配器的例子。一个孔套在棘齿上，棘齿的每个边的尺寸是相同的。在美国典型的边长为1/2''和1/4''。显然，如果不使用一个适配器的话，1/2''的棘齿不能适合1/4''的孔。一个1/2''至1/4''的适配器具有一个1/2''的阴槽来套上一个1/2''的齿，同时有一个1/4的阳槽来卡入1/4''的扳手。图6：使用扳手适配器例子的适配器对象图桥接（Bridge）举例桥接模式将抽象部分与它的实现分离，使它们能够独立地变化。一个普通的开关控制的电灯、电风扇等等，都是桥接的例子。开关的目的是将设备打开或关闭。实际的开关可以是简单的双刀拉链开关，也可以是调光开关。图7：使用电子开关例子的桥接对象图组合（Composite）例子组合模式将对象组合成树形结构以表示部分-整体的层次结构。让用户一致地使用单个对象和组合对象。虽然例子抽象一些，但是算术表达式确实是组合的例子。算术表达式包括操作数、操作符和另一个操作数。操作数可以是数字，也可以是另一个表达式。这样，2+3和（2+3）+（4*6）都是合法的表达式。图8：使用算术表达式例子的组合模式对象图装饰（Decorator）举例装饰模式动态地给一个对象添加额外的职责。不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。图9：使用有画框的画作为例子的装饰模式对象图外观（Facade）举例外观模式为子系统中的接口定义了一个统一的更高层次的界面，以便于使用。当消费者按照目录采购时，则体现了一个外观模式。消费者拨打一个号码与客服代表联系，客服代表则扮演了这个外观，他包含了与订货部、收银部和送货部的接口。图10：使用电话订货例子的外观模式对象图享元（Flyweight）举例享元模式使用共享技术有效地支持大量细粒度的对象。公共交换电话网（PSTN）是享元的一个例子。有一些资源例如拨号音发生器、振铃发生器和拨号接收器是必须由所有用户共享的。当一个用户拿起听筒打电话时，他不需要知道使用了多少资源。对于用户而言所有的事情就是有拨号音，拨打号码，拨通电话。图11：使用拨号音发生器例子的享元模式对象图代理（Proxy）模式代理模式提供一个中介以控制对这个对象的访问。一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。图12：使用银行存单例子的代理模式对象图架构设计中的方法学(4)——团队设计（1）团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想成为团队，有很多的工作要做。我们之所以考虑以团队为单位来考虑架构设计，是因为软件开发本身就不是一件个人的事情，架构设计更是如此。单个人的思维不免有考虑欠妥之处，单个人的学识也不可能覆盖所有的学科。而组织有效的团队却能够弥补这些缺憾。谁来负责架构的设计？在我们的印象中，总认为架构设计是那些所谓架构设计师的专属工作，他们往往拥有丰富的设计经验和相关的技能，他们不用编写代码，就能够设计出理论上尽善尽美的架构，配有精美的图例。问题1：理论上设计近乎完美的架构缺乏程序的证明，在实际应用中往往会出这样那样的问题。问题2：设计师设计架构带有很大的主观性，往往会忽视客户的需求，导致架构无法满足需求。问题3：实现的程序员对这种架构有抵触的情绪，或是因为不理解架构而导致架构实现的失败。问题4：架构师设计架构主要是依据自己的大量经验，设计出的架构不能真实的反映目前的软件需要。解决办法团队设计的理论依据是群体决策。和个人决策相比，群体决策的最大好处就是其结论要更加的完整。而群体决策虽然有其优点，但其缺点也是很明显的：需要额外付出沟通成本、决策效率低、责任不明确、等等。但是群体决策如果能够组织得当的话，是能够在架构设计中发挥很大的优势的。避免象牙塔式的架构设计对软件来说，架构设计是一项至关重要的工作。这样的工作交给某个人是非常危险的。即便这个人再怎么聪明，他也可能会遗漏部分的细节。组织有效的团队的力量是大大超过个人的力量的，因此团队的成果较之个人的成果，在稳定性和思考的周密程度上，都要更胜一筹。ScottW.Ambler在其著作中给出了象牙塔式架构（ivorytowerarchitecture）的概念：Anivorytowerarchitectureisonethatisoftendevelopedbyanarchitectorarchitecturalteaminrelativeisolationtotheday-to-daydevelopmentactivitiesofyourprojectteam(s).中国现在的软件开发行业中也逐渐出现了象牙塔式的架构设计师。这些架构师并不参与实际的程序编写，他的工作就是为项目制作出精美的架构模型，这种架构模型在理论上是相当完美的。例1：在XP中，我们基本上看不到架构设计的影子。并不是说采用XP技术的团队就不需要架构设计。XP不存在专门的设计时期，它提倡使用一些简单的图例、比喻的方式来表达软件的架构，而这种的架构设计是无时无刻不在进行的。其实，XP中的设计采用的就是团队设计的方式，结队编程（PairProgramming）和代码的集体所有制（CollectiveOwnership）是团队设计的基础，也就是基于口述的沟通方式。通过采用这样的方式，XP几乎不需要文档来表达架构的设计。优秀的架构师能够充分的利用现有框架，减少软件的投入，增强软件的稳定性。这些都没有错，但是问题在于“过犹不及”。象牙塔式架构师往往会出现文章开始指出的那些问题。架构设计其实并不是非常复杂的工作，但它要求开发人员具备相关的技能、经验以及对问题域有一定的了解。开发人员往往都具有相关的技术技能（编程、数据库设计、建模），而对问题域的理解可以从用户和行业专家那里获得帮助。因此，在理论上，我们要实现架构设计的团队化是完全可能的。在上面的象牙塔式架构定义中，我们看到架构师和日常的开发工作是隔绝的。这样设计出的架构有很大的局限性。在现实中，我们还会发现另外一种角色，他来自于开发团队外部，为开发人员提供相关的技术或业务的培训。这种角色称为教练，在软件开发中是非常重要的角色，不能够和象牙塔式架构设计师之间画等号。选择你的设计团队软件的架构在软件的生命周期的全过程中都很重要，也就是说，软件开发团队中的所有人员都需要和架构打交道。因此，最好的团队组织方式是所有开发人员都参与架构的设计，我们称这种方式为全员参与。全员参与的方式保证了所有开发人员都能够对架构设计提出自己的见解，综合多方面的意见，在全体开发人员中达成一致。这种方式尤其适合于一些小的团队。还是会有很多的团队由于种种的原因不适合采用全员参与的方式。那么，组织优秀的开发人员组成设计组也是比较好的方式。一般，我们选择那些在项目中比较重要的，有较多开发经验，或是理论扎实的那些人来组成设计组。当然，如果你考虑到为组织培养后续力量，你也可以让一些新手加入设计组，或是你觉得自己的开发力量不足，邀请外部的咨询力量介入，这完全取决于具体的情况。设计组不同于我们之前提到的象牙塔式架构设计师。设计组设计出来的架构只能称为原始架