当前位置：首页 > news >正文

C++设计模式与软件工程

news 来源：原创 2025/6/17 11:14:12

C++设计模式与软件工程

1. 设计模式（Design Patterns)
*问题类型：

你了解哪些常见的设计模式？（至少能说出单例、工厂、观察者、装饰器、策略、状态等）
- 创建型模式：
  - 创建型模式：
    - 单例模式 (Singleton)： 确保一个类只有一个实例，并提供全局访问点。
    - 工厂方法模式 (Factory Method)： 定义一个创建对象的接口，但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
    - 抽象工厂模式 (Abstract Factory)： 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
    - 建造者模式 (Builder)： 将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。
    - 原型模式 (Prototype)： 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
  - 结构型模式：
    - 适配器模式 (Adapter)： 将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
    - 装饰器模式 (Decorator)： 动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。
    - 代理模式 (Proxy)： 为其他对象提供一种代理以控制对这个对象的访问。
    - 外观模式 (Facade)： 为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
    - 桥接模式 (Bridge)： 将抽象部分与它的实现部分分离，使它们都可以独立地变化。
    - 组合模式 (Composite)： 将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
    - 享元模式 (Flyweight)： 运用共享技术有效地支持大量细粒度的对象。
  - 行为型模式：
    - 观察者模式 (Observer)： 定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
    - 策略模式 (Strategy)： 定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。策略模式使得算法可独立于使用它的客户而变化。
    - 命令模式 (Command)： 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
    - 状态模式 (State)： 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
    - 职责链模式 (Chain of Responsibility)： 为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
    - 模板方法模式 (Template Method)： 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
    - 迭代器模式 (Iterator)： 提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
    - 中介者模式 (Mediator)： 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
    - 访问者模式 (Visitor)： 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
    - 备忘录模式 (Memento)： 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
拥挤(享元)模式的意图、结构、优缺点和适用场景？
- 意图： 运用共享技术有效地支持大量细粒度对象的复用。它通过共享已经存在的相似对象来大幅减少创建对象的数量和内存占用，从而解决因大量相似对象导致系统资源（尤其是内存）过度消耗的“拥挤”问题。
- 结构：
  - Flyweight： 定义享元对象的接口，通过这个接口 Flyweight 可以接受并作用于外部状态 (extrinsic state)。
  - ConcreteFlyweight： 实现 Flyweight 接口，并为内部状态 (intrinsic state) 增加存储空间。该状态必须是可共享的，且与 ConcreteFlyweight 对象的上下文无关。
  - UnsharedConcreteFlyweight (可选)： 并非所有 Flyweight 子类都需要被共享。Flyweight 接口使共享成为可能，但它并不强制共享。
  - FlyweightFactory： 创建并管理 Flyweight 对象。它确保合理地共享 Flyweight：当用户请求一个 Flyweight 时，FlyweightFactory 对象提供一个已创建的实例或者创建一个（如果不存在的话）。
  - Client： 维护一个对 Flyweight 的引用；计算或存储 Flyweight 的外部状态 (extrinsic state)。
- 优点：
  - 极大减少内存中对象的数量。 这是最主要的目标。
  - 外部状态相对独立，不会影响内部状态，使得享元对象可以在不同环境中被共享。
- 缺点：
  - 系统复杂性增加。 需要分离出内部状态和外部状态，这使得逻辑复杂化。
  - 为了节省内存而引入共享，可能造成运行时间上的开销。 (例如，查找共享对象、传递外部状态)。
  - 牺牲了可读性。 代码可能变得更加晦涩难懂。
- 适用场景：
  - 一个应用程序使用了大量的相似对象。
  - 由于使用大量对象，造成很大的存储开销。
  - 对象的大部分状态可以外部化（变为外部状态），并且可以用相对较少的共享对象取代大量独立对象。
  - 不依赖于对象标识的应用。 因为共享对象，它们可能没有唯一的标识。
  - 经典例子：
    - 文本编辑器中的字符对象（字符代码是内部状态，位置、字体等是外部状态）。
    - 图形系统中的棋子/图标对象（形状、颜色是内部状态，位置是外部状态）。
    - 游戏中的子弹、敌人等大量重复出现的对象（类型、基础属性是内部状态，位置、血量等是外部状态）。
    - 数据库连接池、线程池（连接/线程对象是享元，连接字符串/配置是内部状态，当前SQL/任务状态是外部状态）。
手写实现一些常见设计模式（如单例模式的懒汉/饿汉实现，线程安全问题）？
你在项目中如何应用设计模式的？

在实际项目中，我会根据具体需求和场景选择合适的设计模式来提升代码的可维护性、可扩展性、可读性和复用性。以下是一些典型的应用例子：
- 单例模式： 用于创建全局唯一的配置管理器 (ConfigManager.getInstance())、数据库连接池 (ConnectionPool.getInstance())、日志记录器 (Logger.getInstance())。
- 工厂方法/抽象工厂模式： 用于创建不同类型的数据库连接 (MySQLConnectionFactory, PostgreSQLConnectionFactory)，创建不同主题的UI控件 (DarkThemeFactory, LightThemeFactory)，创建不同支付网关处理器 (AlipayProcessorFactory, WechatPayProcessorFactory)。
- 观察者模式： 实现事件通知系统（如用户注册成功后通知邮件服务和积分服务）、实现MVC架构中Model和View的松耦合（Model状态改变通知View更新）、实现自定义的异步任务状态监听。
- 策略模式： 封装不同的排序算法 (BubbleSortStrategy, QuickSortStrategy)、不同的验证规则 (EmailValidatorStrategy, PhoneValidatorStrategy)、不同的折扣计算策略 (PercentageDiscountStrategy, FixedAmountDiscountStrategy)。在运行时根据条件切换策略。
- 装饰器模式： 为数据流（如 FileInputStream, BufferedInputStream, GZIPInputStream）动态添加缓冲、压缩、加密等功能。为日志记录器添加时间戳装饰、文件输出装饰等。
- 适配器模式： 集成第三方库时，其接口不符合项目要求，创建适配器类进行转换。让遗留的老接口适配新的系统接口。
- 代理模式： 实现远程方法调用（RMI stub）、实现懒加载（虚拟代理）、实现访问控制（保护代理）、添加日志记录（日志代理）。
- 模板方法模式： 定义数据处理流程骨架（打开连接 -> 读取数据 -> 处理数据 -> 关闭连接），将具体的数据处理步骤延迟到子类实现。
选择模式的核心是识别问题（重复代码？紧耦合？创建复杂？行为多变？），然后看模式意图是否匹配该问题，最后评估引入模式的代价（复杂性增加）是否值得带来的好处（解耦、复用、扩展性）。避免为了用模式而用模式。

2.软件工程实践
*问题类型：

SOLID 原则是什么？如何考核C++开发？
- SRP（单一职责）：每个类仅有一个变更原因（如UserRegistration仅处理注册，EmailSender仅处理发邮件）。
- OCP（开闭原则）：通过扩展（继承/组合）而非修改实现新功能（如使用抽象Shape类扩展Rectangle）。
- LSP（里氏替换）：子类可无缝替换基类（如HumanPlayer替换Player不影响逻辑）。
- ISP（接口隔离）：客户端仅依赖所需接口（如拆分为IPrinter、IScanner而非臃肿接口）。
- DIP（依赖倒置）：高层模块依赖抽象（如Client通过Service接口调用而非具体实现）。
C++开发考核要点：
- 代码设计：检查类职责是否单一、继承是否满足LSP、是否通过抽象解耦。
- 架构理解：评估对多态、模板的应用是否符合OCP和DIP。
- 重构能力：考察对违反SOLID的代码的重构方案（如拆分大类、引入抽象层）
测试驱动开发（TDD）？

核心流程：红-绿-重构循环：
1. 红：先写失败测试（如测试未实现的函数边界条件）。
2. 绿：写最少代码通过测试。
3. 重构：优化代码结构，保持测试通过。
优点：
- 高代码覆盖率与文档性（测试即用例）。
- 提升信心，减少回归缺陷。
  缺点：
- 学习曲线陡峭，需额外培训。
- 可能忽略全局算法优化（仅满足当前测试）。
适用场景：长期维护的核心模块（如算法库、基础服务）
代码规范、版本控制（Git）？

代码规范：
- 命名：变量/函数名需自描述（如get_user_name()而非get_data()）。
- 格式：统一缩进、括号风格（可通过Clang-Format自动化）。
- 注释：关键逻辑需说明意图（非复述代码）。
Git规范：
- 分支模型：
  
  模型 适用场景 特点
  Git Flow 大型项目（如电商平台）多分支（feature/release/hotfix）
  GitHub Flow 快速迭代（如小程序）仅main+功能分支
- 提交信息：采用Angular规范（类型+作用域+主题）：
```
feat(login): 增加OAuth认证支持  
- 集成Google登录API  
- 优化错误处理逻辑  
Closes #123   
```
代码审查（Code Review）？

流程：
- 提交前评审：发起合并请求（MR），由资深开发者审核设计合理性。
- 提交后评审：自动化检查（如静态分析）后人工复核边界条件。
审查重点：
- 可读性：命名、函数长度（建议≤30行）。
- 健壮性：异常处理、资源泄漏（如C++的RAII应用）。
- 性能：避免冗余拷贝、复杂算法误用。
  最佳实践：单次审查≤400行代码，时长≤90分钟。
重构（Refactoring）？

定义：在不改变行为的前提下优化代码结构（如拆分函数、引入设计模式）。
时机：
- 添加功能前：调整旧代码适应新需求。
- 修复Bug时：清理相关代码提升可读性。
  原则：
- 小步进行：每次重构后立即验证测试。
- 工具辅助：依赖IDE自动化（如重命名、提取方法）。
  关键挑战：缺乏测试时需谨慎验证（如通过代码比对工具）。