這個問題的背景是基于一個實際示例，我想從一對用于管理對共享資源的讀/寫鎖定訪問的類中刪除“ 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設計開始）？