软件系统设计复习往年题

作者： zzb

2023-06-17

软件系统设计

字数统计: 9.6k | 阅读时长≈ 34 分钟

软件系统设计复习往年题+2023回忆

参考自 zhy 的博客 2021-软件系统设计-Exam0-往年考试 - SpriCoder的博客

feat: 新增2023回忆，修改原来的部分回忆题

1. 简答题

1.1. 软件系统架构

✅ 【gao’p】如何进行质量属性方案建模？请使用"刺激-相应"图的格式进行建模 How to model quality attribute scenarios? Graphically model one quality attributes in “stimulus-response” format:
【2015】availiability and Performance
【2017】【2018】availiability and modifiability
【2019】interoperability and modifiability
如何进行质量属性方案建模
1. 刺激（Stimulus）：当其到达系统时需要考虑的状况。
2. 刺激源（Source of Stimulus）：产生刺激的实体（人，系统或任何其他触发），可能是输入、信息等，对当前的状态的一个变化。
3. 响应（Response）：刺激到来后工件开展的行为。
4. 响应度量（Response Measure）：对刺激的响应以某种方法进行测量，以便可以测试需求（比如多长时间系统有反馈）
5. 环境（Environment）：发生刺激时系统的状况，例如系统正常运行、系统过载、系统受到攻击、系统网络出现故障等。
6. 工件（Artifact）：完成需求的整个系统或者系统的一部分（软件制品）。

✅ 【高频 2015 2017 2019 2022】为什么软件系统架构需要使用不同视图来文档化？给出 4 种示例视图的名称和目的。Why should a software architecture be documented using different differenet views? Give the name and purposes of 4 example views.
1. 原因
  1. 不同视图支持不同的目标和用户，突出不同的系统元素和关系
  2. 不同视图将不同质量属性暴露出不同的程度
2. 4 种视图 ( 了解 )：
  1. 模块视图 Module View：提供一组连贯职责的实现单元
  2. 组件和连接器视图 C & C View：显示运行时行为和交互的元素
  3. 分配视图 Allocation View：描述了软件单元到环境元素的映射
  4. 质量视图 Quality Views，安全视图、性能视图、可靠性视图、通信视图、异常（错误处理）视图
  5. 组合视图：将上述视图进行组合
✅ 如何选择视图：
1. 构建涉众/视图表
2. 合并视图
3. 确定优先级和完成阶段
✅ 【2017】【2019】描述 4+1 视图 Describe 4+1 view( 掌握绘图 )：答案如上
1. 逻辑视图：描述了对架构而言重要的元素和他们之间的关系（功能需求）
2. 过程视图：描述了元素之间的交互。
3. 物理视图（部署视图）：描述了主要过程和组件是如何被映射到硬件上的。
4. 开发视图（实现视图）：描述实现系统功能的各个组件和模块是如何实现的
5. 用例场景（Use Case）：描述系统的参与者（用户）与系统功能用例的关系，与一个或多个特定视图相关。

✅【高频 2015 2017 2018】什么区分了软件产品线架构和单个软件产品架构？What distinguishes an architecture for a software product line from an architecture for a single product?
1. 产品线的目的：实现高可重用性、高修改性。而单个软件产品不需要很高的重用性和可拓展性
2. 产品线之所以有效是因为通过重用可以充分利用产品的共性。
3. 软件产品线架构倾向于采用更多的模块化和标准化设计，单一产品架构专注于满足单一产品的特定需求，因此模块化和标准化程度较低。
✅ 【高频 2015 2017 2023】将以下每个问题（左侧）与解决该问题的架构风格/视图（右侧）对应起来。列出每个样式类别的四个视图。Map each of the following questions (on the left) with the architectural style/view (on the right) that addresses the question. List four views of each category of style.
1. 连线题
  1. 它是如何构建为一组实现单元的？How it is structed as a set of implementation of units(Module Styles)
  2. 它是如何构建为一组具有运行时行为和交互的元素的？How it is structed as a set of elements that have runtime behavior and interactions?(Component-Connector Styles)
  3. 它与环境中的非软件结构有何关系？How it relates to non-software structures in its environment?(Allocation Styles)
2. Module Styles：分解视图、使用视图、泛化视图、分层视图、领域视图、数据模型视图
3. Component-Connector Styles：管道-过滤器视图、客户端-服务器视图、点对点视图、面向服务视图、发布-订阅视图
4. Allocation Styles：部署视图、安装视图、工作分配视图、其他分配视图。
✅【2015】【2017】简要描述软件架构过程中的一般活动，以及每个活动的主要输入和输出。Briefly describe the general activities in a software architecture process, and the major inputs and outputs at each activity.
1. 短答案 ( 背 )
  1. 识别 ASRs
    1. 输入：无
    2. 输出：优先的质量属性场景
  2. 架构设计
    1. 输入：优先的质量属性场景、需求和约束、模式和决策
    2. 输出：一组由模式决定的候选视图的草图
  3. 架构文档化
    1. 输入：一组由模式决定的候选视图的草图
    2. 输出：View & Beyond
  4. 架构评估
    1. 输入：View & Beyond、优先的质量属性场景
    2. 输出：View & Beyond

✅ 【2015】【2017】【2021】【2023】描述架构权衡分析方法 (ATAM) 过程的每个阶段生成的输出。Describe the outputs generated from each phase of Architecture Tradeoff Analysis Method(ATAM) process.
1. 阶段-0：准备和建立团队 ( 输入是架构设计文档 )
  1. 评估计划
2. 阶段-1：评估-1
  1. 架构的简明介绍
  2. 业务目标（驱动因素）的阐释
  3. 作为场景实现的特定质量属性要求的优先级列表
  4. Utility Tree 质量属性效用树
  5. 风险点和无风险点
  6. 敏感点和权衡点
3. 阶段-2：评估-2
  1. 涉众们的优先级场景列表
  2. 风险主题和业务驱动因素各自受到的威胁
4. 阶段-3：后续
  1. 最终的评估报告
【2019】描述在 ATAM 的每一个过程中有哪些 Stack holder 和他们的职责
1. 阶段-0：准备和建立团队
  1. 参与者：评估团队领导和关键项目决策者
  2. 职责：根据架构设计文档生成评估计划，包括谁参加评估、如何何时何地开展评估、最后评估报告会被呈递给谁。
2. 阶段-1：评估-1
  1. 参与者：评估团队和项目决策者
  2. 职责：
    1. 第一步，评估负责人介绍 ATAM 方法
    2. 第二步，项目经理或客户从业务角度介绍业务驱动因素
    3. 第三步，首席架构师介绍体系结构
    4. 第四步，评估团队确定架构方法
    5. 第五步，评估团队和项目决策者生成质量属性效用树 (Utiltiy Tree)
    6. 第六步，评估团队分析架构方法
3. 阶段-2：评估-2
  1. 参与者：评估团队、项目决策者和项目涉众
  2. 职责：
    1. 第一步，评估负责人介绍 ATAM 方法和之前已经取得的成果
    2. 第七步，涉众头脑风暴并确定场景优先级
    3. 第八步，评估团队分析架构方法，类似第六步
    4. 第九步，评估团队展示评估结果，并呈递给涉众
4. 阶段-3：后续
  1. 参与者：评估团队、主要涉众
  2. 职责：评估团队制作最终评估报告，发给主要涉众审核通过后，将报告呈递给委托评估的人。
✅ 【2015】【2019】软件架构来自哪里？列举五种可能的软件架构的来源 Where do software architecture come from? List five possible sources of software architecture.
1. NFRs - 非功能性需求
2. ASRs
3. 涉众
4. 技术环境
5. 业务目标
✅ 【2015】【2019】解释代理架构模式的上下文、好处和局限性。Explain the context, benefits and limitations of Broker Architecture Pattern.
1. 上下文：多个同步或异步交互的远程对象组成的系统，broker协调多个客户机和服务器之间的通讯。
2. 好处：提高了 Client 和 Server 之间的交互性、提高可伸缩性和可扩展性、解决了单体应用的性能瓶颈、大规模集群的性能提高，但是单点性能会下降。
3. 局限性：代理增加了前期复杂度、可能成为通信的屏障、可能成为攻击的目标、难以测试。
4. SOA 延续了 broker 的思想，查找服务和使用服务都要通过 broker，而 SOA 只在查找时通过 register，分散了 broker 的职责，降低了单点风险。
✅ 【2018】【2023】Layered pattern 和 Multi-tier pattern 的区别
1. Layered Pattern 是 Module Style，而 Multi-tier Pattern 是 Allocation Style
2. Layered Pattern 是将任务拆解成一个个处于特定抽象级别的子层次，每层为上一层提供服务，核心是关注点分离。
3. Multi-tier Patten 中的层是逻辑的组合，没有层次模式的强依赖关系，在不同部署环境中分层不同但是软件完成的内容一致。
✅ 【2017】【2019】【2022】【2023】在设计软件时应用了哪些通用设计策略？为每个策略提供一个带有软件架构的简明工作示例。What are generic design strategies applied in designing software? Give a concise working example with software architecture for each strategy.
1. 抽象：关注本身结构而不关心实现，比如将系统抽象为组件和连接件或抽象为模块。
2. 分解：比如将整个系统分解或将某个模块分解。
3. 分而治之：将每个模块分别处理
4. 生成与测试：将一个特定的设计看作是一个假设；根据测试路径生成测试用例。
5. 迭代与细化：如 ADD 方法多次迭代直到满足所有 ASR
6. 复用元素：重用在设计过程中出现了可以复用的元素，重用现有架构
✅ 【2017】【2019】什么是 ASR？列出提取和识别 ASR 的四种来源和方法。What are ASR? List four sources and methods for extracting and identifying ASRs.
1. ASRs 架构攸关需求是对架构产生深远影响的需求
2. 四种来源和方法：
  1. 从需求文档中收集 ASR：MoScoW 方法和用户故事
  2. 通过采访涉众来收集 ASR：质量属性工作坊 (QAW)Quality Attribute Workshop
  3. 通过了解业务目标来收集 ASR：
  4. 通过质量属性效用树 (Utility Tree) 来收集 ASR*：逐渐对质量属性进行分解细化，直到包含量化指标为止。*
✅ 【2017】【2019】典型的软件架构文档包中应该包含哪些内容？简要描述每个组件及其用途。What should be included in a typical software architecture documentation package? Briefly describe each component and its purpose.
1. 包含 View 和 Beyond
2. Beyond 部分：
  1. 文档路线图：包含了范围和总结、简单摘要等。
  2. 视图的文档组织方式：描述了本文档中视图是如何组织的。
  3. 系统概述：从整体上描述了当前架构的简要说明、业务目标 ( 驱动因素 ) 等等。
  4. 视图之间的映射关系：描述了不同视图之间的映射关系。
  5. 系统原理：从整体上描述了当前架构的设计原理。
  6. 目录-索引、词汇表、首字母缩略词表。
3. View 部分
  1. styles and views( 体系结构风格和视图 )
  2. Structural views
    1. module viwes
    2. C & C views
    3. Allocation views
  3. Quality Views
4. 每一个 View 的内容
  1. 主要介绍：显示视图的元素和关系，以及图例
  2. 元素介绍，详细介绍第一部分中描述的元素、元素属性、关系属性和元素接口和行为。
  3. 上下文图：描述系统如何与环境相关
  4. 可变性指导：告知视图中可能出现的变化
  5. 基本原理：解释设计如何映射在视图中，以及其合理性。
✅ 【2015】描述架构设计中架构模式和tactics 之间的关系。给出可以在架构设计过程中使用的任何四种决策的名称，并描述每种决策的目的。Describe the relationships between architectual patterns and tactics in architecture design. Give name of any four tactics that can be used during architecture design and describe the purpose of each of them.
1. 架构模式与tactics 之间的关系
  1. tactics 比模式更简单，使有单一的结构或机制来应对单一的架构驱动
  2. tactics 是构成架构模式的重要组成部分
  3. 架构模式通常将许多个tactics 组合在一起。
  4. 大多数架构模式都包含不同的tactics ，这些tactics 可能有共同的目的或者常被用于实现不同的质量属性。
  5. tactics 和架构模式共同构成了软件设计时的工具。
2. 四种决策的名称
✅ 【2015】简要描述面向服务架构 (SOA) 的基本原则，并讨论 SOA 对互操作性、可伸缩性和安全性等质量属性的影响 Briefly describe the fundamental principles of Service Oriented Architecture(SOA) and discuss the impact of SOA on quality attributes like interoperability, scalability and security
1. SOA 的基本原则
  1. 服务解耦：服务之间的关系最小化，只是相互知道接口
  2. 服务契约:服务按照描述文档所定义的服务契约行事
  3. 服务封装:除了服务契约所描述内容，服务将对外部隐藏实现逻辑
  4. 服务重用:将逻辑分布在不同的服务中，以提高服务的重用性
  5. 服务组合:一组服务可以协调工作，组合起来形成定制组合业务
  6. 服务自治:服务对所封装的逻辑具有控制权
  7. 服务无状态:服务将一个活动所需保存的资讯最小化
2. SOA 对互操作性的影响
  1. SOA 具有更高的互操作性：符合开放标准，可以更好的重用服务
  2. 支持服务的自动识别、发现、注册和调用等等
3. SOA 对可伸缩性的影响
  1. SOA 具有更高的可伸缩性：服务自身高内聚、服务间松耦合，最小化维护的影响
  2. 但是 SOA 也会带来系统复杂度较高的问题
4. SOA 对安全性的影响：
  1. 中间件可能会成为性能的瓶颈
  2. ESB 等中间件都可以成为被攻击的目标
  3. 多服务导致攻击的跟踪、溯源和防御成为困难。
✅ 【2019】【2023】微服务和 SOA 的区别，相同点
1. 相同点：微服务和 SOA 都是分布式架构，微服务架构可以看作是SOA的一种实现方式，适用于更小规模和更灵活的应用系统。都包含了服务契约、服务封装、服务重用、服务组合、服务自治和服务无状态等基本特点。
2. 微服务去掉了 SOA 架构中的 ESB(Enterprise Service Bus) 企业服务总线，采用轻量级通信机制 (HTTP、REST) 进行服务之间的通信。
3. 微服务引入了熔断器：避免出现服务失效或网络问题等导致的级联故障。
4. 部署和扩展：在SOA中，整个应用程序通常作为一个单元进行部署和扩展。而在微服务架构中，每个微服务可以独立部署和扩展，使得系统具有更好的弹性和可伸缩性。
5. 服务粒度：在SOA中，服务的粒度可以比较大，一个服务可能涵盖多个相关的业务功能。而在微服务架构中，服务的粒度更小，每个服务通常专注于一个特定的业务功能。
6. 组织和治理：SOA通常需要涉及企业范围内的中央治理和管理，**不能控制独立服务的演变。**而微服务架构强调团队的自治性，每个微服务可以由一个独立的团队进行开发和管理，更加注重服务的自治性和快速迭代。
【2017】软件设计的三个变化维度，每个维度的变化点。不同的绑定时间如何影响可修改性和可测试性。
1. 三个变化维度：
  1. 面向对象 OOP，强调重用性、灵活性和扩展性。
  2. 面向方面 AOP，满足扩展的需求，可以在程序中自由的扩展功能
  3. 面向服务 SOA，是系统发布功能的一种方式，且基于这种方式下不同的系统之间可以有效的沟通、协作。
2. 设计时，开发时，测试时，发布时，运行时：可修改性降低，可测试性升高
✅【2018】软件架构的关注点有哪些？利益相关方有哪些？
1. 软件架构的关注点
  1. 利益相关者 Stakeholders addressed
  2. 解决的问题 Concerns addressed
  3. 语言，建模技巧 Language, modeling techniques
  4. 策略，模式 Tactics, Pattern
2. 利益相关方有哪些？
  1. 顾客 Customer
  2. 用户 User
  3. 架构师 Architect
  4. 需求工程师 Requirements engineer
  5. 设计师 Designer
  6. 实施者 Implementer
  7. 测试师，集成师 Tester, integrator
  8. 维护者 Maintainer
  9. 产品经理 Product manager
  10. 质量保证人 Quality assurance people
✅ 【2018】【2022】Software requirements, Quality attributes, ASRs 的区别和联系
1. 软件需求包括功能性需求和非功能性需求（又称质量需求）
2. 质量属性是由软件的业务目标所决定，在功能性需求的基础上提供的整个系统的合乎需求的特性，是非功能需求的一种体现。
3. ASRs 架构攸关需求是对于体系结构有着深远影响的需求，肯定是软件需求的一部分。
✅ 【2018】描述 ADD 过程

输入：需求，输出：软件元素 - 角色 - 职责 - 属性 - 关系
1. 确定有足够的需求信息
2. 选择要分解的系统要素
3. 确定所选的元素的 ASR
4. 选择符合 ASR 的设计
  1. 找出设计问题
  2. 列出子关注点替代模式/策略
  3. 从清单中选择模式/策略
  4. 确定模式/策略与 ASR 之间的关系
  5. 记录初步的架构视图
  6. 评估并解决不一致的问题
5. 实例化架构元素并分配职责
6. 实例化元素定义接口
7. 验证和完善需求
8. 重复进行 2-7 步直到满足所有的 ASR
✅ 【2019】Architecture，structure 和 Design 的区别？
1. Design 包含 Architecture，Architecture 包含 Structure
2. 结构是静态的、逻辑的，是关于系统如何构成的
3. Architecture除包含structure ，还会包含组件之间的相关的关系结构，并定义一些动态的行为。
4. 所有体系结构都是设计，但是不是所有的设计都是体系结构，体系结构是软件设计的一个部分
✅ 【2018】【2019】【2022】Risks，Senstivity Points，Trade-Off Points 分别是什么？各举一个例子。
1. 识别风险：发现可能对所需质量属性产生负面影响的架构决策，例如使用分层模式可能带来性能损耗。
2. 发现权衡：影响多个质量属性的架构决策，例如使用分层模式可能会带来性能损耗，但是增加系统的可修改性。
3. 发现敏感点：特定质量属性对其敏感的架构决策，比如在对性能敏感的系统中，决定使用缓存中间件。
✅ 软件架构风格
1. module Styles：认为体系结构是由模块组成。模块是实现单元的集合，它提供了一组一致的职责。
2. C & C Styles 认为体系结构是由组件 ( 主要的处理单元和数据存储 )、连接件 ( 组件之间的交互路径 ) 组成的。
3. Allocation Styles 认为体系结构是由软件元素 ( 软件元素具有环境所需的属性 ) 和环境元素 ( 环境元素有提供给软件的属性 ) 组成的，展示了软件如何与环境关联。
架构模式是：⼀个架构模式是⼀组架构设计决定，这些决定适用于重复出现的设计问题，并被参数化以考虑出现该问题的不同软件开发上下文。
软件架构是程序或计算系统的结构，由软件元素、这些元素外部可⻅的属性、这些元素的关系组成
架构模式：{问题，上下文} → 架构方法。架构风格具体到常见的问题和上下文，就叫做架构模式

1.2. 设计模式

【2017】请至少说出三个面向对象的原则，并解释它们如何应用于策略模式？ Please name at least three Object-Oriented principles, and explain how they are applied in Strategy pattern?
1. 单一职责原则
2. 开闭原则
3. 里氏代换原则
4. 合成复用原则
【2019】设计模式是什么？举例说明类模式和对象模式的区别？
1. 什么是设计模式：
  1. (PPT)设计模式 (Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
2. 设计模式分类
  1. 根据其目的 ( 模式是用来做什么的 ) 可分为创建型 (Creational)，结构型 (Structural) 和行为型 (Behavioral) 三种：
    1. 创建型模式主要用于创建对象。
    2. 结构型模式主要用于处理类或对象的组合。
    3. 行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。
  2. 根据范围，即模式主要是用于处理类之间关系还是处理对象之间的关系，可分为类模式和对象模式两种：
    1. 类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。
    2. 对象模式处理对象间的关系，这些关系在运行时刻变化，更具动态性。
【2019】防御式编程是什么？断言和错误处理的区别？
1. 可以预见到（至少预先推测到）问题所在，断定代码中每个阶段可能出现的错误，并作出相应的防范措施，来防止类似的意外的发生。
2. 断言和错误处理的区别
  1. 断言是在开发期间使用的、让程序在运行时进行自检的代码，是对开发人员的警告，通常是一个子程序或宏。断言不可以有副作用。
  2. 错误处理是对预先已经考虑到的错误 ( 如用户错误、程序错误、意外情况等等 ) 按照流程进行处理。
【2019】设计模式对 MVC 的影响？
1. MVC 模式使用了运行时、动态和相互之间的关系集成到开发框架中，是分层模式的变种。
  1. 分为 model（业务逻辑）、view（处理用户展示，接收用户操作）、controller（对用户操作进行处理，将信息通知给 model）（强调模块间约束关系，model 不可以直接返回到 controller）
  2. 优点：耦合性低，重用性高，生命周期成本低，部署快，可维护性高，方便管理
  3. 缺点：没有明确定义，不适于中小型应用程序，增加实现复杂度，视图和控制器过于紧密，视图对模型访问低效。
2. 四人书中，MVC 模式是观察者模式、策略模式和组合模式的演化，可能涉及到工厂模式和装饰器模式
  1. 基于推送-订阅模式
  2. 观察者：model 发生变化通知 controller，然后更新 view
  3. 策略模式：controllers 帮助 views 对不同用户的输入做不同的响应。
  4. 组合模式：一组 views
【2019】【2023】策略模式和状态模式的区别？
1. 在状态模式中，具体状态类的方法参数中包含上下文对象，需要在状态处理完成后完成状态切换。
2. 在策略模式中，直接对上下文类调用 set 方法设置策略即可，不涉及到策略的切换。
【2019】最小知识原则在设计模式中的应用？
1. 中介者模式
2. 外观模式
【2022】Please explain the Liskov Substitution Principle and how it contributes to the Open- Closed Principle
1. LSP要求子类能够完全替代父类，而不会破坏原有系统的行为
2. LSP对于开闭原则（Open-Closed Principle，OCP）的贡献在于，它确保了代码的可扩展性。OCP要求软件实体应该对扩展开放，对修改关闭。当我们遵循LSP时，可以通过添加新的子类来扩展系统的功能，而无需修改已有的代码。因为子类完全替代父类，所以可以将新的子类对象传递给原有代码，而不会影响原有代码的正确性。这样，我们可以通过增加新的子类来实现系统的扩展，同时保持原有代码的稳定性和一致性
【2022】【2023】观察者设计模式中有两种方法用于向观察者传播数据：推模型（Push Model）和拉模型（Pull Model）。为什么有些情况下一个模型会比另一个模型更可取？每个模型的权衡是什么？

推模型和拉模型的选择取决于应用程序的需求和设计考虑。下面是每个模型的优势和权衡：

推模型：
- 优势：
  1. 简单直接：数据由主题（被观察者）直接推送给观察者，观察者不需要主动请求数据。
  2. 即时性：数据推送是实时的，观察者可以立即收到最新的数据更新。
- 权衡：
  1. 无法控制数据量：在推模型中，主题通常将所有数据推送给所有观察者，无论观察者是否需要这些数据。这可能会导致数据传输过程中的浪费。
  2. 安全性和隐私问题：如果数据包含敏感信息，推模型可能会引发安全和隐私问题，因为数据在推送过程中可能会被截获或访问到。
拉模型：
- 优势：
  1. 灵活性：观察者可以根据需要主动拉取所需的数据，可以减少不必要的数据传输。
  2. 数据控制：观察者可以根据具体情况控制拉取数据的频率和量，从而减少网络带宽和资源消耗。
- 权衡：
  1. 延迟性：拉模型需要观察者主动发起请求才能获取数据，可能会引入一定的延迟。
  2. 实时性限制：观察者只能获取其主动请求的数据更新，无法立即获知所有最新的数据。
【2022】What is the difference between the categories of Creational Patterns and Structural
Patterns
1. 创建型模式（Creational Patterns）和结构型模式（Structural Patterns）是面向对象设计中的两个主要模式分类。
  
  创建型模式关注对象的创建机制和实例化过程，主要用于解决对象的创建和初始化的问题。这些模式将对象的创建与使用代码解耦，使得系统更加灵活和可扩展。创建型模式的例子包括工厂模式、抽象工厂模式、单例模式、建造者模式和原型模式等。
  
  结构型模式关注对象之间的组合和关联关系，主要用于描述对象和类之间的静态结构和组织方式。这些模式通过定义类和对象之间的关系，提供了一种实现系统组件之间协作的方式。结构型模式的例子包括适配器模式、装饰器模式、代理模式、组合模式、外观模式、桥接模式和享元模式等。
  
  行为型模式关注对象之间的交互和职责分配，可以减少对象间的耦合度，提高系统的灵活性和可扩展性。行为型模式的例子包括观察者模式、策略模式、模板方法模式、命令模式、迭代器模式、状态模式、访问者模式和解释器模式等。
类模式和对象模式
1. 类模式是指应用于类层次结构的设计模式。它们关注的是类之间的关系、继承和接口的使用。类模式描述了类之间的静态关系和结构，以及如何通过类的继承、组合和接口实现来达到设计目标。类模式通常通过继承、抽象类、接口等来实现类之间的关系，以及类的行为和功能。
  
  对象模式是指应用于对象层次结构的设计模式。它们关注的是对象之间的交互、通信和协作。对象模式描述了对象之间的动态行为和相互作用方式，以实现特定的功能和行为。对象模式通常通过对象之间的关联、委托、组合、观察者等方式来实现对象的交互和通信。
2. 工厂方法模式注重对象的创建和实例化过程，它通过子类化来延迟具体对象的创建，被归类为类模式。而抽象工厂模式注重对象之间的关联关系和组合，它的目标是提供一种统一的方式来创建一系列相关的对象，被归类为对象模式
3. 由于模板方法模式主要通过基类和子类之间的继承关系来定义算法的框架结构，强调了类之间的静态关系和结构，所以被归类为类模式。
【2021】软件模式是什么？能提供架构吗？
1. 虽然软件模式提供了一些通用的设计思路和原则，但具体的架构设计需要结合具体的问题和需求进行选择和应用。架构设计涉及系统的整体结构、组件之间的关系、数据流和交互方式等方面，需要综合考虑系统的功能需求、性能要求、可扩展性、安全性等因素。因此，软件模式可以作为设计架构的参考和指导，但最终的架构设计需要根据具体情况进行灵活调整和优化。
【2023】装饰者模式为什么比用子类扩展功能有更好的灵活性？
【2023】为什么最小知识原则可以帮助构建高内聚、低耦合的系统？用代码举一个违背的例子
【2022】【2023】What is the benefit of decoupling the Receiver from the Invoker in the Command Pattern?

2. 设计题

【2019】一个游戏，有几种人类角色：骑士、骑兵、步兵，持有不同的武器 ( 矛、剑、斧 )，拥有 fight 方法；有一个非人类角色巨魔，可以持有武器，但攻击方法不同 (beat)。现在希望让巨魔和其他人类角色一起进行游戏，并且要求有角色死亡时其他活着的角色要收到通知。运用设计模式进行设计，并画出类图。
【2019】表驱动，参考 PPT 即可。
【2019】架构设计，没太看懂……大概是分析程序结构生成报告？
【2018】设计一个飞行模拟软件，要求能模拟多种飞机的特性。为了在将来支持更多飞机种类，要求使用策略模式。画出架构图和类图
【2019】一个买票系统的设计题，不同的角色有不同的打折方案，用策略模式设计，最后画图，还要说明策略模式的使用场景。
【2021】【2023】设计⼀个基于管道-过滤器模式的、输⼊⽂本⽂件、输出排序后的⽆重复的单词列表的程序。 1. ⽤组件部分和连接器画出程序图。 2. 画出组件的类图。 3. ⽤ Java 实现每个类。 4. 指出你的代码和 1、2 中图的映射
【2023】设计一个系统，有很多的机器人，他们有不同的功能，在未来会拓展这些功能或功能的复杂性，同时有一批保留了旧接口的老机器人，也希望能加入到这个系统中。系统还能将所有的机器人看作一个 unit 来统一的控制。1. 列出使用的设计模式和类图 2.说明你的设计如何有利于未来拓展功能

【2015】【2019】【2022】

3. 其他知识点

什么是软件系统架构：是结构和系统结构，包含了软件元素，这些组件的外部可视化属性和他们之间的关系（包含组件的行为）
几个概念
1. 功能性需求：定义系统必须做什么，并且强调系统如何提供价值给涉众。
2. 质量需求：系统应在功能性需求之上提供的整个系统的合乎需求的特性。
3. 策略：是影响质量属性相应控制的设计决策，比如冗余。
架构模式
1. 背景、上下文（Context）：世界上经常发生问题的场景。
2. 问题（Problem）：在给定上下文中出现经过适当概括的问题。
3. 解决方案（Element + Relations + Constraints）：针对问题的成功的经过适当抽象的解决方案。
ADD 的输出
1. 软件元素：完成各种决策和职责、定义属性并与其他软件元素相关以组成系统架构的计算或开发工件。
2. 角色：一组相关的职责。
3. 职责：软件提供的功能、数据或信息。
4. 属性：有关软件元素的附加信息。
5. 关系：两个软件元素之间如何相互关联和交互的定义。
如何选择视图
1. 构建涉众/视图表
2. 合并视图
3. 确定优先级和完成阶段
什么是微服务：是分布式架构，SOA 的一种扩展
1. 微服务架构风格是一种将一个单一应用开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制，这些服务围绕业务能力构建并可以通过自动部署机制独立部署。
2. 微服务特点
  1. 服务颗粒化:服务粒度由业务功能决定，服务间尽可能解耦
  2. 责任单一化:单一职责原则，服务内尽可能内聚
  3. 运行隔离化:服务运行在各自进程中，互不影响
  4. 管理自动化:对服务提供自动化部署与监控预警能力，高效管理
3. 微服务核心模式：针对采用微服务系统在特定问题所使用的程序的架构解决方案的集合
  1. 服务注册与发现
  2. API 网关
  3. 熔断器
4. 微服务的挑战
  1. 运维要求高:微服务数量多，部署与监控要求高
  2. 发布复杂度:部署环境多样化，网络性能系统容错、分布式事务等挑战
  3. 部署依赖强:服务间相互调用关系复杂，存在部署顺序依赖
  4. 通信成本高:跨进程调用比进程内调用消耗更多的资源
面向对象设计原则

设计原则
1. 目标：开闭原则
2. 指导：最小知识原则
3. 基础：单一职责原则、可变性封装原则
4. 实现：依赖倒转原则、合成复用原则、里氏代换原则、接口隔离原则
模式一般都有的缺点
1. 增加设计的复杂性和增加类的个数 ( 增加辅助类 )
2. 增加隔阂、方法调用，降低软件运行的效率，但是已经不是目前主要的问题
引入设计模式的作用
1. 设计模式提供了与其他开发人员共享的词汇表。
2. 通过在模式级别（而不是实质性对象级别）进行思考，提高对体系结构的思考（但不要迷失在细节中）

防御式编程
1. 防御式编程：可以预见到（或至少预先推测到）问题所在，断定代码中每个阶段可能出现的错误，并作出相应的防范措施，来防止类似意外的发生。
2. 断言：在开发期间使用的、让程序在运行时进行自检的代码，是对开发人员的警告，通常是一个子程序或宏。断言不可以有副作用。
3. 异常：是将代码中的错误或异常事件传递给调用方代码的一种特殊手段，谨慎使用可以降低复杂度。
4. 错误处理：根据软件类别平衡正确性和健壮性（哪个优先级更高）
5. 隔离程序：隔离程序是以防御式编程为目的而进行隔离的一种方法，将某些接口选定为“安全”区域的边界，对穿越安全区域边界的数据进行合法性检验（集中工作在特定的模块中降成本）
6. 辅助调试代码：辅助进行代码调试的代码，帮助快速检查错误，应该尽早地引入辅助调试代码。
7. 攻击式编程：主动暴露出可能出现的错误，在开发阶段将其暴露显现出来，而在产品代码运行时让他能够自我恢复。
表驱动法：一种编程模式
1. 目的：表驱动法适用于复杂逻辑，将复杂逻辑从代码中独立出来方便单独维护
2. 原理：从表里面查找信息而不使用逻辑语句 (if 和 else)
3. 具体实现
  1. 直接访问表：直接通过索引值可以从表中找到对应的条目
  2. 索引访问表：首先从索引表中找到数据表的地址，然后再从数据表中找到对应的条目 ( 节省空间、管理廉价、容易维护 )
  3. 阶梯访问表：根据每项命中的阶梯层次来确定其归属
装饰者的两个缺点：很多小类、难以排查错误
增加新的鸭叫统计次数 ( 不允许修改原本代码 )：装饰器模式

4. 选择模式

一个温度系统有 3 个恒温器，一个恒温器可以调整和显示温度，2 个恒温器只能手动调节，1 个恒温器可以手动、计时器调节：中介者、策略
1. 模板方法：先调整、再显示 ( 用户直接复用模板方法，而本例中复用的是实现 )
一个队伍有 1 个管理者和 25 个队员，每一个队员可以有一个位置，有的特别强的队员可以有多个位置：策略、原型
1. 策略独立于 Player，所以 Player 是一样的
2. 模板方法模式是解决步骤的问题
积分会员制，积分比较高则为高级会员，积分比较低则为低级会员

版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。