c++ - 哪种设计更好 : provide direct access to an owned object or give owning object forwarding methods to the owned object?

Question

哪个更好:

class Owner
{
public:
    void SomeMethodA()
    {
        _ownee.SomeMethodA();
    }

    int SomeMethodB()
    {
        return _ownee.SomeMethodB();
    }

private:
    Ownee _ownee;
};

或者这个:

class Ownee
{
public:
    void SomeMethodA();
    int SomeMethodB();
};

class Owner
{
public:
    Ownee& GetOwnee() const
    {
        return _ownee;
    }

private:
    Ownee _ownee;
};

我似乎记得很久以前读过第一个选项比第二个选项更好，但我不记得为什么。我想说是因为 Owner 和 Ownee 的用户之间耦合度较低。客户只需要知道所有者的接口(interface)而不是所有者的接口(interface)，而对于第二个选项，客户将需要知道所有者的接口(interface)和所有者的接口(interface)。

Answer 1

一个人并非在所有方面、在任何情况下都优越。但是，包装接口(interface)和封装成员(第一个)通常更可取。

一个类和它的成员有着特殊的关系。一个类通常使用其接口(interface)来限制功能在其预期的域内运行，并且它可用于进行额外的内部状态验证并提高程序的正确性。

当封装良好时，Owner可以根据需要更自由地更改其实现或成员。

公开成员通常会导致更高的耦合度，并最终将大量长期维护工作推给客户端(导致更多错误和客户端的冗余实现)。一个相当明显的例子:假设 Owner有两个成员，并且必须保证线程安全——将这一责任推给客户并期望客户在几年的几次更改中实现和维护线程安全是没有意义的。然而，Owner可以抽象所有这些，并在其实现更改时适本地更改其实现，或者防止成员更改 (Ownee) 在这方面影响客户端。

类的更改(Owner 或 Ownee )通常在其成员未公开时对客户端的影响要小得多，并且类 ( Owner ) 为其功能提供了严格、简单的接口(interface)。

“性能”通常被认为是赞成第二种(“只提供客户端访问器”)的原因。我发现这是毫无根据的过度简化。性能可能更好也可能更差!在开发重要程序时，它依赖于 C++ 中的许多很多东西。同样，使用锁定示例:第一个和/或偏爱公共(public)访问器的不良接口(interface)可能需要更多的锁定。同样，优化器具有信息及其成员的局部性。 Owner 可能提供了大量的内部实现和方法。 -- 如果这在很大程度上是私有(private)的，并且使用静态分派(dispatch)，它可能会导致导出(或内联，如果你喜欢)方法的集合非常少。访问器本身可能并没有那么糟糕，但是访问器的操作和依赖项可能会将大量指令和依赖项推送给您的客户端——当您的内部实现 Owner 时。可以用一个单一的、紧凑的、优化的形式来表示所有这些。在 C++ 中，抽象层在优化时可以非常便宜(如果做得好，通常什么都没有)。在现实世界中，性能会双向波动，并且取决于许多变量。

大多数情况下，我使用第一种形式。当我使用第二种形式时，它通常与:

• 私有(private)/内部类。
• 或作为更大系统的组件(例如元编程)。

阅读:

http://en.wikipedia.org/wiki/Law_Of_Demeter

http://en.wikipedia.org/wiki/Cohesion_(computer_science )

http://en.wikipedia.org/wiki/Coupling_(computer_science )

http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming )

http://en.wikipedia.org/wiki/Information_hiding