软件架构与设计 第 5 课 Architectural Styles

前面我们大致了解了一下整体的系统设计与领域相关知识组合的各种设计阶段，这一讲我们主要来看看架构风格。

---

面向对象风格

这个风格大家应该都比较熟悉了，主要是分为组件和连接器，各个部分都按照面向对象的几个大的原则：封装继承多态来设计。好处在于各个组件分工明确并且不需要关注组件内部实现，自由度比较高。

分层风格

层次结构，层与层之间通过 API 来进行通信，每层对于上下两层扮演服务端和客户端的角色，操作系统就是一个很好的例子。

好处在于增加了抽象层级，并且可以不断进化，改动一层，最多影响两层，很好进行重用。只要保证接口，实现可以多样化，标准化的接口使得库和框架开发都很方便。不好之处在于不是特别通用，过多的抽象也会影响性能。

客户端-服务端风格

组件被分成客户端和服务端两种，服务端对于客户端的数量和身份都未知，但是客户端知道服务端的，不同的连接器基于 RPC 网络交互协议 RPC-based network interaction protocol.

数据流风格

不同的程序按顺序执行，数据在这个过程中进行传递，这里的连接器就类似于一个通道。常用于金融系统的交易处理，称为『The Granddaddy of Styles』

管道和过滤器风格

组件是过滤器，用来处理数据；连接器是管道，用来控制数据流。每个过滤器只知道自己的事情，不知道其他的。例如：Unix Shell，信号处理，分布式系统，并行计算。用代码的话就比如：ls invoices | grep -e August | sort

有一些变种，比如 Pipeline，Bounded pipes 和 Typed pipes。好处在于系统的行为就是组件的连续行为。过滤器可以方便的添加替换和重用，也比较容易分析吞吐量，延迟，死锁等等。对于独立的任务，可以并行处理。

不好的地方在于所有操作批处理容易出现问题，对于交互程序没有办法使用或者比较难用

黑板风格

有两种类型的组件，一种是中央数据结构，叫做黑板，而另一种就是在黑板上操作的组件。系统的控制是基于黑板的状态。例如人工智能系统，集成软件环境，编译器

基于规则风格

组件包括用户界面，推理引擎和知识库，连接器则是紧密相联的（通过过程调用或共享内存），数据元素是事实和查询。系统的行为可以通过增加规则来方便地修改。但是大量的规则可能会导致冲突和难以理解

解释器风格

解析和执行输入命令，然后根据解释器来更新状态。组件包括：命令解释器，程序状态，用户界面。连接器则是紧密相联的（通过过程调用或共享内存）

这种风格非常灵活，但是对于用户的要求很高，例如 Lisp 和 Scheme

Mobile-Code 风格

这个风格的主要思想是，组件是一个可以执行各类代码的工具，然后具体的代码可以通过不同的来源输入并执行

Implicit Invocation 风格

这种风格是事件声明而非方法调用。有一个侦听器来检测方法是否被请求，具体什么时候执行由系统决定。WPF 的编程模型有一种就是如此。好处在于组件可以重用，无论是在构建阶段还是使用阶段都可以进行系统演化。不好之处在于这种设计比较反直觉，具体的控制需要系统计算。实际也不知道哪个组件在处理也不知道什么时候处理。

发布订阅风格

同步或异步广播，然后接受者接收到了进行对应的处理，通常经过网络协议。数据类型包括 Subscription, notification 和 published information

Subscribers connect to publishers either directly or may receive notifications via a network protocol from intermediaries

基于事件风格

不同的组件异步发出和接受小溪，通过事件总线进行连接。

Components communicate with the event buses, not directly to each other.

非常高的拓展性，对分布式系统有很好的支持

点对点风格

每个组件都是一个小的自治系统，一般来说通过网络协议（通常自定义）来进行沟通，互相发送网络消息。

Network (may have redundant connections between peers) can vary arbitrarily and dynamically

具有很高的鲁棒性，但是后期协议可能会是问题（因为规模越来越大）

这一讲是各个风格的简要介绍，具体还是要在实例中进行学习和分析