機能を犠牲にすることなく友人の依存関係を削除できますか?

同時アクセス管理のフレンド依存関係を再考する

はじめに

この記事では、共有リソースへの同期読み取り/書き込みアクセスの管理を担当する 2 つのクラス間の「フレンド」依存関係を削除しようとするときに直面する課題を詳しく掘り下げます。フレンド依存関係は、ClassAAccessor に ClassA の保護されたメソッドへのアクセスを提供する手段として導入され、クライアントが ClassAAccessor とそのライフサイクル動作を通じてのみ ClassA と対話するようにします。

フレンド依存関係について

元の設計は、ClassA と ClassAAccessor の間のフレンド依存関係に依存していました。この依存関係により、ClassAAccessor は ClassA の保護されたメソッドにアクセスできるようになり、共有リソースのロックとロック解除を管理できるようになりました。ただし、フレンドの依存関係の使用は、メンテナンスの問題が発生する可能性など、さまざまな理由から推奨されません。

リファクタリング プロセス

フレンドの依存関係を削除するには、次の 3 つの手順に従います。ステッププロセス:

1. 抽象インターフェイスの導入: 以前はフレンド宣言を介してアクセスできた操作を表すために、抽象インターフェイス InternalInterface を作成します。 ClassA は InternalInterface の実装になりますが、一般化はカプセル化を維持するために保護されます。
2. インターフェイスへの操作の移動: 「呼び出し」依存関係を作成した操作 (以前はfriends) は ClassA から InternalInterface に移動されます。これにより、インターフェイスと実装の間に明確かつ明示的な関係が確立されます。
3. 実装の結合: 実装では、ClassAAccessor が InternalInterface への参照を取得する方法を提供し、次のことを可能にします。必要な操作にアクセスします。これは、ClassAccessor が InternalInterfaceRef 変数を設定できるようにする ClassA のメソッドによって実現されます。

利点と欠点

このアプローチには、次のような利点があります。

• 問題のあるフレンド依存関係の削除
• 保守性の向上と結合の減少

ただし、考慮すべきデメリットもいくつかあります。

• 抽象インターフェイスの導入によるコードの複雑さの増加
• フレンド宣言を使用する場合と比較してパフォーマンスが低下する可能性があります (ただし、これは慎重に実装することで軽減できます)

結論

説明した手順に従うことで、目的の機能を維持しながら、フレンドの依存関係を削除する設計のリファクタリングに成功しました。このリファクタリングにより、保守性の向上などのいくつかの利点がもたらされると同時に、そのような変更に伴う潜在的なトレードオフも強調されます。

以上が機能を犠牲にすることなく友人の依存関係を削除できますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。