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