我注意到，当您遵循良好的软件工程原则（例如demeter法则）时，您最终会复制功能接口。
例如，Demeter的定律导致编写“包装函数”，它只是将工作委托给类的内部对象。
代码示例：
class A{
public:
void doSomething(){
internalObj_.doSomething();
}
private:
SomeType internalObj_;
}
如果A类有很多私有对象，它的界面会变得非常庞大。
问题： 什么时候重复接口合理？换句话说，复制10个函数是否可以，但没有更多？函数的数量不重要，是否有另一个度量标准，当我完成足够的函数接口重复时，我可以“感知”它？
请用你的答案给我一些推理。
答案 0 :(得分：2)
在您引用的这个特定情况下，几乎可以肯定的是，如果您明确使用inline，编译器将内联包装器，从而不会导致运行时损失。
这里唯一的费用是额外的打字工作/冗余/等等......在重大的方案中，如果有必要让你在课堂上重新实现公共接口，那么它会给你额外的灵活性。 class实现功能本身，而不是将其委托给其他人。
答案 1 :(得分：1)
例如，Demeter定律导致写入＆＃34;包装函数＆＃34;只需将工作委托给该类的内部对象。
如果发生这种情况，通常会出现设计不良的气味。抽象通常提供更高级别的界面，而不是简单地聚合他们的内部。
如果A类有很多私有对象，那么它的界面会非常庞大。
如果一个班级有很多私人物品，那通常就是设计不好的气味。您应该瞄准Single Responsibilty Priciple，这通常会使成员数量保持在较低水平。
当您将公共接口与私有接口分开时，复制接口是最常见的，其中复制用于解耦。