在 C 中有两种明显的方法可以提供对内部属性值的外部访问（A）提供一个通用接口，该接口接受随时间变化的属性列表（一些添加/一些死亡）或（B）一个特定接口每个属性。
示例 A：
int x_get_attribute_value(ATT att)
{
if (a) return a_val;
if (b) return b_val;
}
示例 B：
A_Enum x_get_a_type_attribute() {}
B_Enum x_get_b_type_attribute() {}
我记得 Eclipse 的 API 非常像 A（我可能是错的）。我不能做的是提出一个令人信服的论据来反对。
A 是干净的 - 任何用户都无法找到属性值。它可以干净利落地进化而不会留下死接口。
B 有一定程度的类型检查 - 这是 C 枚举！
是否有一个重要的论点可以使平衡远离舆论？
【问题讨论】：
B 引入新属性的开销要大得多。将新属性引入稳定的软件分支将承担许多风险，因为必须从根本上更改接口。
根据我的个人经验，总的来说，我会为 A 担保。
很大程度上还取决于软件集成的紧密程度。借用 Booch 的术语，选项 A 促进弱耦合，而 B 促进软件组件之间的强耦合。
如果您希望能够冻结界面，使其长时间稳定，禁止任何更改，那么 B 将允许您这样做：添加新属性是高度可见的。如果您希望能够随时添加新属性，当您期望拥有大量属性时，那么选项 A 显然是最受欢迎的。
您也可以考虑将两者结合使用。让重要属性具有专用的获取/设置功能。对于其他不太重要的选项，请使用通用 get/set 函数。如果某个属性变得重要，则可以为其引入专用的 get/set。
注意显然不应该忘记性能：选项 B 在任何微基准测试中都会赢得 A。
【讨论】：
A 是您最好的选择，因为您可以更轻松地更改其背后的机制。你可以有一个 ifs 的阶梯，一组可以循环的可接受属性，或者一个哈希表，没有人会比这更聪明。
【讨论】：
如果你想支持各种类型的选项（整数、字符串等），那么 A 是行不通的，因为 C 函数只能返回一种类型的值。
你当然可以让函数返回一个void* 并对结果进行类型转换，但这只是自找麻烦。
简而言之，如果您想要/需要支持多种类型的选项，解决方案 B 是您的最佳选择。
【讨论】：