面试题：C++类成员访问属性设计原则与复杂软件架构

Question

在一个大型的C++软件项目中，有多个模块，每个模块都包含众多的类，且类之间存在复杂的继承和组合关系。请从类成员访问属性设计原则的角度出发，阐述如何设计类成员的访问权限，以提高模块的独立性、可维护性和安全性。可以结合具体的架构场景，比如分层架构或微服务架构进行说明，并分析违反这些设计原则可能带来的潜在问题。

Answer 1

1. 类成员访问属性设计原则

• 封装原则：
  • 私有成员（private）：将类的内部实现细节，如数据成员和实现特定功能的成员函数，设为私有。例如，在一个数据库访问模块中，数据库连接字符串、连接句柄等敏感信息应设为私有。这防止外部直接访问和修改，保证数据完整性和安全性。
  • 公有成员（public）：提供给外部调用的接口设为公有。比如数据库访问类的 query 函数，用于执行SQL查询，应设为公有，使其他模块能通过该接口与数据库交互。
  • 保护成员（protected）：主要用于继承关系中。若模块采用分层架构，如数据访问层继承自基础数据操作层，基础数据操作层的一些辅助函数可能设为保护，允许子类（数据访问层的类）访问，而外部其他类无法访问。
• 信息隐藏原则：尽可能隐藏类的内部实现细节，只通过公有接口与外部交互。这提高模块独立性，降低模块间耦合。例如，在微服务架构中，每个微服务可看作一个模块，微服务内部类的私有成员对其他微服务完全隐藏，仅通过暴露的RESTful接口（类似于公有成员函数）进行通信。

2. 结合分层架构说明

假设采用三层分层架构（表现层、业务逻辑层、数据访问层）。

• 数据访问层：
  • 数据访问类的数据库连接相关成员设为私有，防止业务逻辑层或表现层直接修改连接参数。公有成员函数如 getUserData 用于从数据库获取用户数据，供业务逻辑层调用。
  • 如果有基础数据访问类供其他数据访问类继承，基础类中一些通用的数据转换函数可设为保护，方便子类复用。
• 业务逻辑层：
  • 业务逻辑类的私有成员用于存储业务处理过程中的临时数据，如计算订单总价时的中间变量。公有成员函数如 processOrder 调用数据访问层接口获取数据并进行业务处理，然后返回结果给表现层。
  • 若业务逻辑层有分层（如通用业务逻辑和特定业务逻辑），通用业务逻辑类的一些辅助函数可设为保护供特定业务逻辑类继承使用。
• 表现层：
  • 视图类的私有成员用于管理界面元素的状态，如按钮是否可用。公有成员函数如 updateUI 根据业务逻辑层返回的数据更新界面。

3. 结合微服务架构说明

在微服务架构中，每个微服务是独立的模块。

• 例如用户管理微服务，用户类的私有成员存储用户敏感信息，如密码哈希值。公有成员函数如 getUserInfo 用于向其他微服务提供用户公开信息。
• 若有基础微服务功能类供多个微服务继承（如日志记录功能），基础类中的日志记录函数可设为保护，允许继承的微服务使用，而外部其他微服务无法直接调用。

4. 违反设计原则的潜在问题

• 模块独立性降低：若过多将类成员设为公有，其他模块可随意访问和修改内部状态，模块间耦合度增加。例如，在分层架构中，若数据访问层类的数据库连接成员设为公有，业务逻辑层可能直接修改连接参数，导致数据访问层功能不稳定，且两个层之间耦合过紧，难以独立维护和扩展。
• 可维护性变差：违反封装原则，内部实现细节暴露，当内部实现改变时，可能影响众多依赖该实现的外部模块。如微服务中，若类的私有成员直接被其他微服务访问，私有成员的修改可能导致其他微服务出错，增加维护成本。
• 安全性问题：敏感数据若设为公有或保护不当，可能被非法访问和修改。比如用户类的密码哈希值若不是私有，可能被其他模块获取，存在安全风险。