相关疑难解决方法(0)

这个问题的背景是基于一个实际的示例,我想从一对用于管理对共享资源的读/写锁定访问的类中删除«friend»依赖项.

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

标记为红色,我想从设计中删除这个丑陋的"朋友"依赖.

简而言之,为什么我在那里有这个东西:

1. ClassAProvider共享对ClassA多个并发访问Client实例的引用
2. Client实例应该ClassA只通过ClassAAccessor管理内部的辅助类来访问
3. ClassA将所有打算使用的方法隐藏起来ClassAAccessor.
4. 因此ClassA可以确保Client需要使用ClassAAccessor实例

ClassA如果Client操作失败(因为例如未捕获的异常),则该模式主要用于确保将实例保留在已定义的状态.考虑 ClassA提供(内部可见的)配对操作,如lock()/ unlock()或open()/ close().

在任何情况下都应调用(state-)反转操作,尤其是当客户端由于异常而崩溃时.
这可以通过ClassAAcessor生命周期行为安全地处理,析构函数实现可以确保它.以下序列图说明了预期的行为:

此外,只需使用C++范围块,Client实例就可以ClassA轻松实现对访问的精确控制:

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

到目前为止一切都很好,但由于一些很好的理由ClassA,ClassAAccessor应该删除之间的"朋友"依赖关系

1. 在UML 2.2超结构,第C.2节中,在以前的UML的变化下,它说: The following table lists …