在德墨忒耳定律和过多的接口重复之间取得平衡的任何指导

any guidance to balance between law of demeter and too much interface duplication?

本文关键字：之间 任何指 平衡 接口 定律      更新时间：2023-10-16

我注意到，当你遵循良好的软件工程原理（如得墨忒耳定律）时，你经常会复制函数接口。

例如，Demeter 定律导致编写"包装函数"，这些函数只是将工作委托给类的内部对象。

代码示例：

class A{
public:
    void doSomething(){
        internalObj_.doSomething();
    }
private:
    SomeType internalObj_;
}

如果类 A 有很多私有对象，它的接口可能会变得非常大。

问题：何时重复接口是合理的？换句话说，是否可以复制 10 个函数，但不能再复制？函数的数量是否无关紧要，当我完成了足够的函数接口复制时，是否有另一个指标可以"感知"？

请用你的答案给我一些理由。

在您引用的这种特定情况下，几乎可以肯定的是，如果您要显式使用inline编译器将内联包装器，而不会造成运行时损失。

这里唯一的费用是额外的打字工作/冗余/等......在宏伟的计划中，如果有必要让类实现功能本身，而不是将其委托给其他人，则可以在将公共接口重新实现到您的类方面为您提供额外的灵活性。

例如，Demeter 定律导致编写"包装函数"，这些函数只是将工作委托给类的内部对象。

如果发生这种情况，通常是糟糕设计的气味。抽象通常提供更高级别的接口，而不是简单地聚合其内部。

如果类 A 有很多私有对象，它的接口可能会变得非常大。

如果一个类有很多私人对象，这通常是糟糕设计的味道。您应该瞄准通常会使成员数量较少的Single Responsibilty Priciple。

当您将公共接口与私有接口分开时，复制接口最为常见，其中重复用于解耦。

相关文章：