这个问题的背景是基于一个实际示例,我想从一对用于管理对共享资源的读/写锁定访问的类中删除“ friend”依赖项。
这是该方案的原始结构设计的抽象:
用红色标记,我要从设计中删除这种难看的“ friend”依赖项。
简而言之,为什么我要在这里放东西:
ClassAProvider共享对ClassA多个并发访问Client实例的引用
Client实例应ClassA仅通过ClassAAccessor管理内部的助手类进行访问
ClassA隐藏所有打算使用的方法,使其处于ClassAAccessor受保护状态。
这样ClassA可以确保Client需要使用ClassAAccessor实例
如果要确保操作失败(例如由于未捕获的异常)ClassA,则在确保将实例保留在定义的状态时,这种模式非常有用Client。考虑 ClassA提供类似lock()/ unlock()或open()/的(内部可见的)配对操作close()。
在任何情况下都应调用(状态)反转操作,尤其是当客户端由于异常而崩溃时。
可以通过ClassAAcessor的生命周期行为来安全地处理此问题,析构函数的实现可以确保这一点。下面的序列图说明了预期的行为:
另外,仅使用C ++范围块,Client实例就可以实现对ClassA轻松访问的精细控制:
// ...
{
ClassAAccessor acc(provider.getClassA());
acc.lock();
// do something exception prone ...
} // safely unlock() ClassA
// ...
到目前为止,一切都很好,但是由于多种原因ClassA,ClassAAccessor应该删除和之间的“朋友”依赖项
在UML 2.2上层建筑,下从以前的UML更改部分C.2,它说: The following table lists predefined standard elements for UML 1.x that are now obsolete. ... «friend» ...
我见过的大多数编码规则和准则都禁止或强烈不鼓励使用友人,以避免从导出类到友人的紧密依赖。这件事带来了一些严重的维护问题。
正如我的问题标题所说
如何正确删除/重构朋友声明(最好从我的类的UML设计开始)?
浮云间
相关分类