架构设计中的方法学.pdfVIP

架构设计中的方法学 架构设计是一种权衡（trade-off ）。一个问题总是有多种的解决方案。而我们要确定唯一的架 构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个权衡。我们在设计的过程 总是可以看到很多的矛盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一 对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必 然会影响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计的复杂度。 没有一个软件能够满足所有的要求，因为这些要求之间带有天生的互斥性。而我们评价架构 设计的好坏的依据，就只能是根据不同要求的轻重缓急，在其间做出权衡的合理性。 目标 我们希望一个好的架构能够： 重用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。 重用是我们不断追求的目标之一，但事实上，做到这一点可没有那么容易。在现实中，人们 已经在架构重用上做了很多的工作，工作的成果称为框架（Framework ），比如说 Windows 的窗口机制、J2EE 平台等。但是在企业商业建模方面，有效的框架还非常的少。 透明：有些时候，我们为了提高效率，把实现的细节隐藏起来，仅把客户需求的接口呈 现给客户。这样，具体的实现对客户来说就是透明的。一个具体的例子是我们使用 JSP 的tag 技术来代替 JSP 的嵌入代码，因为我们的HTML 界面人员更熟悉 tag 的方式。 延展：我们对延展的渴求源于需求的易变。因此我们需要架构具有一定的延展性，以适应未 来可能的变化。可是，如上所说，延展性和稳定性，延展性和简单性都是矛盾的。因此我们 需要权衡我们的投入/产出比。以设计出具有适当和延展性的架构。 简明：一个复杂的架构不论是测试还是维护都是困难的。我们希望架构能够在满足目的 的情况下尽可能的简单明了。但是简单明了的含义究竟是什么好像并没有一个明确的定义。 使用模式能够使设计变得简单，但这是建立在我熟悉设计模式的基础上。对于一个并不懂设 计模式的人，他会认为这个架构很复杂。对于这种情况，我只能对他说，去看看设计模式。 高效：不论是什么系统，我们都希望架构是高效的。这一点对于一些特定的系统来说尤 其重要。例如实时系统、高访问量的网站。这些值的是技术上的高效，有时候我们指的高效 是效益上的高效。例如，一个只有几十到一百访问量的信息系统，是不是有必要使用 EJB 技术，这就需要我们综合的评估效益了。 安全：安全并不是我们文章讨论的重点，却是架构的一个很重要的方面。 规则 为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则： 功能分解 顾名思义，就是把功能分解开来。为什么呢？我们之所以很难达到重用目标就是因为我 们编写的程序经常处于一种好像是重复的功能，但又有轻微差别的状态中。我们很多时候就 会经不住诱惑，用拷贝粘贴再做少量修改的方式完成一个功能。这种行为在 XP 中是坚决不 被允许的。XP 提倡Onceandonlyonce，目的就是为了杜绝这种拷贝修改的现象。为了做到 这一点，我们通常要把功能分解到细粒度。很多的设计思想都提倡小类，为的就是这个目的。 所以，我们的程序中的类和方法的数目就会大大增长，而每个类和方法的平均代码却会 大大的下降。可是，我们怎么知道这个度应该要如何把握呢，关于这个疑问，并没有明确的 答案，要看个人的功力和具体的要求，但是一般来说，我们可以用一个简单的动词短语来命 名类或方法的，那就会是比较好的分类方法。 我们使用功能分解的规则，有助于提高重用性，因为我们每个类和方法的精度都提高了。 这是符合大自然的原则的，我们研究自然的主要的一个方向就是将物质分解。我们的思路同 样可以应用在软件开发上。除了重用性，功能分解还能实现透明的目标，因为我们使用了功 能分解的规则之后，每个类都有自己的单独功能，这样，我们对一个类的研究就可以集中在 这个类本身，而不用牵涉到过多的类。 根据实际情况决定不同类间的耦合度 虽然我们总是希望类间的耦合度比较低，但是我们必须客观的评价耦合度。系统之间不 可能总是松耦合的，那样肯定什么也做不了。而我们决定耦合的程度的依据何在呢？简单的 说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的 需求，我们完全可以把各类设计成紧耦合的（我们虽然讨论类之间的耦合度，但其实功能块、 模块、包之间的耦合度也是一样的），因为这样可以提高效率，而且我们还可以使用一些更 好的技术来提高效率或简化代码，例如 Java 中的内部类技术。可是，