| 软 件 类 型 | 架 构 模 式 | 特 点 和 用 途 |
| 系统软件 | 分层（Layer） | 从不同的层次来观察系统，处理不同层次问题的对象被封装到不同的层中 |
| 管道和过滤器（Pipes and Filters） | 用数据流的观点来观察系统，整个系统由一些管道和过滤器组成，需要处理的数据通过管道传送给每一个过滤器，每个过滤器就是一个处理步骤。当数据通过了所有的过滤器后，就完成了所有的处理操作，得到最终的处理结果。ＵＮＩＸ操作系统的管道模型就建立在这样的架构之上；在ＵＮＩＸ下进行开发时，每个进程都是一个过滤器，我们可以通过管道把进程连接起来，让所有的过滤器在协作中完成整个任务。大多数程序设计语言的编译器也是基于这种架构模式实现的。 | |
| 黑板（Blackboard） | 在这种架构中，在两种不同的构件;一种是表示当前的状态的中心数据结构；另一种是一组相互独立的构件，这些构件对中心数据进行操作。这种架构主要用于数据库和人工智能系统的开发。 | |
| 分布式软件 | 经纪人(Broker) | 在这种架构中，客户和服务器通过一个经纪人部件进行通信，经纪人负责协调客户和服务器之间的操作。并且为客户和服务器发送请求和结果信息。Broker就是经纪人模式的典型应用。 |
| 客户/服务器(Client/Server) | 系统分为客户和服务器，服务器一直处于侦听的状态，客户主主动连接服务器，每个服务器可以为多个客户服务。 | |
| 点对点（Peer to Peer） | 系统中的结点都处于平等的地位，每个结点都可以连接其他结点。在这种架构中，一般需要由一个中心服务器完成发现和管理结点的操作。我们熟悉的ＩＣＱ程序以及WEB Service技术的大多数应用，都是典型的点对点结构。 | |
| 交互软件 | 模型－视图－控制器(Model-View-Controller) | 当应用程序的用户界面非常复杂，且关于用户界面的需求很容易变化时，我们可以把交互类型的软件抽象成抽模型，视图和控制器这三类组件单元，这种抽象可以很好地分离用户界面和业务逻辑，适应变化的需求。大多数现代交互软件都在一定程序上符合这一架构模型的特点。 |
| 显示－抽象－控制器(Presentation-Abstraction-Control) | 这是显示－抽象－控制器模式的另一种变形，这里就不再详细介绍了 |
设计的最终目地是最大限度的实现代码复用，如果不能达到复用代码的目地，就没有必要再提取出新类了，（属性就是，某个共性比较小的代码，所以没有必须把属性给提出来变成类。如果有多个类调用它，就可以提出新类）。
时间： 2024-11-02 23:23:30