架构风格分类
| 五大架构风格 | 简介 | 子风格 |
|---|---|---|
| 数据流风格 | 面向数据流，按照一定的顺序从前向后执行程序 | 批处理、管道-过滤器 |
| 调用/返回风格 | 构件与构件之间存在相互调用的关系，一般是显示的调用 | 主程序/子程序、面向对象、层次结构（层次型架构风格） |
| 独立构件风格 | 构件之间是相互独立的，不存在显式的调用关系，而是通过事件触发、异步的方式执行 | 进程通信、事件驱动系统（隐式调用） |
| 虚拟机风格 | 自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配 | 解释器、规则系统 |
| 以数据为中心（仓库风格） | 以数据为中心，所有的操作都是围绕建立的数据中心进行 | 数据库系统、黑板系统、超文本系统 |
| 其他未分类风格 | 闭环-过程控制：反馈循环，接收一定的输入，确定一系列的输出，最终使环境达到一个新的状态C2风格：通过连接件绑定在一起的按照一组规则运行的并行构件网络 |
常考风格
不全是教材内容，主要理解并区分各种架构风格，如何选用正确的架构风格。以前爱考案例对比几种风格的优缺点，最近两次没考（改版后），以后不确定还考不考，可以看一下
1. 管道/过滤器
将数据处理分为多个处理程序（过滤器），每个过滤器负责独立的处理逻辑，处理结果通过管道传给下一个过滤器
- 可修改性：高。每个过滤器相互独立，修改某个过滤器不会影响其他过滤器，容易调整。
- 灵活性：高。通过调整过滤器的顺序或组合新的过滤器，可以灵活修改数据流和处理方式。
- 性能：高。适合并行处理数据流，但多个过滤器间的数据传递可能带来性能开销。
- 可扩展性：高。可以通过增加或替换过滤器来扩展系统功能。
- 交互性：低。过滤器之间通过数据流进行交互，没有直接通信，交互性较弱。
2. 面向对象风格
将软件设计成对象，封装数据和行为，支持继承和多态
- 可修改性：中高。通过封装和继承机制，类和对象可以独立修改，但复杂的对象继承结构可能增加修改难度。
- 灵活性：高。通过多态和继承等特性，系统可以灵活扩展和适应变化，但复杂的继承关系可能带来维护难度。
- 性能：中。性能取决于对象之间的调用频率和层次深度，可能有性能开销。
- 可扩展性：高。可以通过扩展类、继承和实现接口来增加功能，具备良好的可扩展性。
- 交互性：中高。对象通过方法调用进行交互，但过于复杂的对象关系可能导致交互困难。
3. 事件驱动风格
系统行为由事件触发，通过事件处理程序响应不同的事件
- 可修改性：高。事件处理器是松耦合的，可以独立修改不影响其它模块
- 灵活性：高。异步和解耦使得事件处理器可以灵活添加或删除，适合应对动态变化的需求
- 性能：高。通常采用异步处理，但事件复杂或过多事件会导致性能瓶颈
- 可扩展性：高。可以通过添加新的事件处理器或修改事件流来扩展系统
- 交互性：高。通过事件发布和订阅机制实现松耦合的组件交互，交互灵活且动态
4. 分层风格
将系统分为多个层次，每个层次只与相邻层交互
- 可修改性：中高。某一层的修改不影响其它层，但跨层修改时会产生较大的变动
- 灵活性：中。各层职责分明，但修改可能需要跨层修改，限制了系统的灵活性
- 性能：中。多层之间的调用会引入额外的性能开销，特别是在跨层次操作频繁时。
- 可扩展性：中高。可以通过增加或修改某一层的功能来扩展系统，但过多的层次可能导致复杂性增加。
- 交互性：中。交互通常是上下层之间的调用，跨层交互较为复杂。
5.数据共享风格
多组件共享一个数据存储，组件之间通过读取和修改共享数据进行通信
- 可修改性：低。由于多个组件依赖同一个共享数据，数据结构的修改会影响所有组件。
- 灵活性：低。系统高度依赖共享数据，灵活性较差，系统变更时难以快速适应
- 性能：中低。集中式数据访问可以提升一致性，但高并发访问会引起竞争和瓶颈，降低系统性能
- 可扩展性：低。由于多个模块共用一个数据源，扩展新的功能或组件时需要重新设计数据结构
- 交互性：中低。组件之间通过共享数据进行间接交互，依赖数据的一致性
6.解释器风格
对输入数据（如编程语言）进行解析为指令并执行，通常用于实现特定的语言或格式
- 可修改性：高。可以通过修改解释器或脚本语言来轻松改变系统行为，无需重新编译整个系统。
- 灵活性：高。系统可以在运行时动态解释新规则或指令
- 性能：中低。解释执行的性能通常低于编译执行，特别是在处理复杂指令时性能瓶颈较为明显
- 可扩展性：高。通过增加新的指令或规则集扩展解释器功能
- 交互性：低。解释器通常执行线性指令，交互性较弱，但可以通过扩展语言功能增强交互
7.基于规则的系统风格
系统通过一组“if-else”规则进行推理和决策，根据输入条件匹配相应的规则并执行相应的操作。
- 可修改性：高。规则可以独立添加、修改和删除，不影响系统的整体模块
- 灵活性：高。可以动态调整或扩展规则集，灵活应对需求变化
- 性能：中。规则数量如果较多则会面临性能瓶颈
- 可扩展性：高。可以通过添加新的规则和推理机制来扩展系统功能
- 交互性：中。规则间的交互通过推理引擎间接实现，规则之间的依赖性可能影响交互效率
8. 闭环控制风格
系统通过监测输出并根据反馈调整输入，形成一个闭环控制
- 可修改性：低。控制回路通常固定，修改一个环节可能影响整个系统的稳定性和性能
- 灵活性：低。闭环控制系统具有固定的反馈结构，调整和扩展的灵活性较差
- 性能：高。通常注重快速响应和系统稳定，性能出色
- 可扩展性：低。扩展新功能或添加新控制回路可能需要重新设计系统
- 交互性：中。交互通常局限在传感器和控制器之间，交互方式单一
这个看熟了，如果出到论文也可以应对一番，不过改版后架构风格的权重低了
