Question

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 enums！

是否有一个重要的击球手论证推动平衡远离意见？

Answer 1

B引入新属性的开销更大。将新属性引入稳定的软件分支将带来许多风险，因为必须从根本上改变界面。

根据我的个人经验，一般来说，我会保证A。

很多还取决于软件的集成程度。借用Booch的术语，选项A促进弱耦合，而B促进软件组件之间的强耦合。

如果您希望能够冻结界面，使其在很长一段时间内保持稳定，禁止任何更改，那么B将允许您这样做：添加新属性非常明显。如果您希望能够随时添加新属性，当您希望有大量属性时，那么选项A显然是最受欢迎的。

你也可以考虑两者的健康组合。对于具有专用get / set功能的重要属性。对于使用通用get / set函数的其他不太重要的选项。如果某个属性变得很重要，可以为它引入专用的get / set。

N.B。显然，人们不应该忘记性能：选项B将在任何微基准测试中赢得A.

Answer 2

A是您最好的选择，因为您可以更轻松地更改其背后的机制。你可以有一个ifs的阶梯，一个可以接受的可接受属性的数组，或者一个哈希表，没有人会更聪明。

Answer 3

如果要支持各种类型的选项（整数，字符串等），则A是非启动器，因为C函数只能返回一种类型的值。你当然可以让函数返回一个void*并对结果进行类型转换，但这只是在寻找麻烦。

简而言之，如果您需要/需要支持多种类型的选项，解决方案B就是您的选择。