如何正确删除/重构«friend»依赖声明？

Question

这个问题的背景是基于一个实际示例，我想从一对用于管理对共享资源的读/写锁定访问的类中删除“朋友”依赖项。

这是该场景的原始结构设计的抽象：

标记为红色，我想从设计中删除这个丑陋的“朋友”依赖项。

总之，我为什么会有这个东西：

1. ClassAProvider 共享对 ClassA 的引用超过了 同时访问Client 实例
2. Client 实例应仅通过 ClassAAccessor 辅助类访问 ClassA 管理内部的
3. ClassA 将所有打算从 ClassAAccessor 使用的方法隐藏为受保护的。
4. 所以ClassA可以保证Client需要使用ClassAAccessor实例

这种模式主要是有用的，当它确保将ClassA 的实例留在 定义的状态，如果 Client 操作退出（例如由于未捕获的异常）。考虑到 ClassA 提供（内部可见的）配对操作，例如 lock()/unlock() 或 open()/close()。

在任何情况下都应该调用（状态）反转操作，尤其是当客户端由于崩溃而崩溃时 例外。
这可以通过ClassAAcessor的生命周期行为，析构函数来安全处理 实施可以保证。 以下序列图说明了预期的行为：

另外Client 实例可以轻松实现对ClassA 访问的精细控制，只需使用 C++ 范围块：

// ...
{ 
    ClassAAccessor acc(provider.getClassA());
    acc.lock();
    // do something exception prone ...
} // safely unlock() ClassA
// ...

到目前为止一切正常，但是出于多种原因，应该删除 ClassA 和 ClassAAccessor 之间的 «friend» 依赖关系

1. 在 UML 2.2 上层结构的 C.2 节中，从以前的 UML 的变化下它说：The following table lists predefined standard elements for UML 1.x that are now obsolete. ... «friend» ...
2. 我见过的大多数编码规则和指南都禁止或强烈反对使用friend，以避免将导出类紧密依赖于friends。这会带来一些严重的维护问题。

正如我的问题标题所说

如何正确删除/重构友元声明（最好从我的类的 UML 设计开始）？

Answer 1

让我们首先为重构设置一些约束：

1. ClassAAccessor 的公开可见界面不得更改
2. ClassA 内部操作不应对公众可见/不可访问
3. 不应损害原始设计的整体性能和占用空间

---

第 1 步：引入抽象接口

在第一次尝试中，我排除了“朋友”的刻板印象，并将其替换为一个类（接口） InternalInterface 和相应的关系。

构成 «friend» 依赖的内容被拆分为一个简单的依赖关系（蓝色）和 对新 InternalInterface 元素的 «call» 依赖项（绿色）。

---

第 2 步：将构成 «call» 依赖项的操作移至接口

下一步是完善 «call» 依赖项。为此，我将图表更改如下：

• «call» 依赖项变成了一个定向关联，来自 ClassAAccessor 到 InternalInterface（即 ClassAAccessor 包含 一个私有变量internalInterfaceRef)。
• 相关操作已从 ClassA 移至 InternalInterface。
• InternalInterface 使用受保护的构造函数进行扩展，它在继承中很有用 仅限。
• ClassA 与InternalInterface 的“泛化”关联标记为protected， 所以它是公开不可见的。

---

第 3 步：在实现中将所有内容粘合在一起

在最后一步，我们需要对ClassAAccessor 如何获得对InternalInterface 的引用进行建模。由于泛化不公开可见，ClassAAcessor 不能再从构造函数中传递的ClassA 引用初始化它。但是ClassA 可以访问InternalInterface，并使用ClassAAcessor 中引入的额外方法setInternalInterfaceRef() 传递引用：

---

这是 C++ 实现：

class ClassAAccessor {
public:
    ClassAAccessor(ClassA& classA);
    void setInternalInterfaceRef(InternalInterface & newValue) {
        internalInterfaceRef = &newValue;
    }
private:  
    InternalInterface* internalInterfaceRef;
};

这个其实是调用的，当时也是新引入的方法ClassA::attachAccessor() 方法被调用：

class ClassA : protected InternalInterface {
public:
    // ...
    attachAccessor(ClassAAccessor & accessor);
    // ...
};

ClassA::attachAccessor(ClassAAccessor & accessor) {
    accessor.setInternalInterfaceRef(*this); // The internal interface can be handed
                                             // out here only, since it's inherited 
                                             // in the protected scope.
}

因此 ClassAAccessor 的构造函数可以改写如下：

ClassAAccessor::ClassAAccessor(ClassA& classA)
: internalInterfaceRef(0) {
    classA.attachAccessor(*this);
}

---

最后，您可以通过引入另一个 InternalClientInterface 来进一步解耦实现，如下所示：

---

至少有必要提到，这种方法与使用friend 声明相比有一些缺点：

1. 代码更加复杂
2. friend 不需要引入抽象接口（这可能会影响占用空间，因此约束 3. 没有完全实现）
3. UML 表示不能很好地支持protected 泛化关系（我不得不使用该约束）

Answer 2

依赖没有说明访问属性或操作。依赖关系用于表示模型元素之间的定义依赖关系！ 如何从模型中删除所有依赖项并学习如何使用可见性。 如果您的朋友关系代表从特定类型（类）访问特征（属性或操作），您可以将属性或操作的可见性设置为包。包可见性意味着，可以从在同一包中定义类的实例访问该属性值。

在同一个包中定义 ClassAProvider 和 Client，并将 classA 属性可见性设置为包可见性类型。客户端实例可以读取classA的属性值，但是同一个包中没有定义的其他类型的实例不能。