Pouvez-vous supprimer les dépendances entre amis sans sacrifier les fonctionnalités ?

Repenser la dépendance entre amis pour la gestion des accès simultanés

Introduction

Dans cet article, nous Plongez dans un défi rencontré lors de la tentative de suppression d'une dépendance « amie » entre deux classes responsables de la gestion de l'accès synchronisé en lecture/écriture à une ressource partagée. La dépendance ami a été introduite comme un moyen de fournir à ClassAAccessor un accès aux méthodes protégées de ClassA, garantissant que les clients n'interagiraient avec ClassA que via ClassAAccessor et son comportement de cycle de vie.

Comprendre la dépendance ami

La conception originale reposait sur une dépendance amie entre ClassA et ClassAAccessor. Cette dépendance permettait à ClassAAccessor d'accéder aux méthodes protégées de ClassA, lui permettant ainsi de gérer le verrouillage et le déverrouillage des ressources partagées. Cependant, l'utilisation de dépendances amies est déconseillée pour diverses raisons, notamment leur potentiel à introduire des problèmes de maintenance.

Processus de refactorisation

Pour supprimer la dépendance amie, nous suivons une procédure de trois : processus par étapes :

1. Présentation d'une interface abstraite : Nous créons une interface abstraite, InternalInterface, pour représenter les opérations qui étaient auparavant accessibles via la déclaration d'ami. ClassA est une implémentation d'InternalInterface, mais la généralisation est protégée pour maintenir l'encapsulation.
2. Déplacement des opérations vers l'interface : Les opérations qui ont créé la dépendance "appel" (précédemment représentée par le ami) sont déplacés de ClassA vers InternalInterface. Cela établit une relation claire et explicite entre l'interface et l'implémentation.
3. Implémentation de collage : Dans l'implémentation, nous fournissons un moyen pour ClassAAccessor d'obtenir une référence à l'InternalInterface, lui permettant de accéder aux opérations nécessaires. Ceci est réalisé grâce à une méthode dans ClassA qui permet à ClassAAccessor de définir sa variable internalInterfaceRef.

Avantages et inconvénients

Cette approche présente des avantages tels que :

• Suppression de la dépendance ami problématique
• Maintenabilité améliorée et réduction du couplage

Cependant, il y a aussi quelques inconvénients à considérer :

• Complexité accrue du code en raison de l'introduction d'une interface abstraite
• Potentiel de performances réduites par rapport à l'utilisation de déclarations d'amis (bien que cela puisse être atténué par une mise en œuvre minutieuse)

Conclusion

En suivant les étapes décrites, nous avons réussi à refactoriser la conception pour supprimer la dépendance aux amis tout en conservant la fonctionnalité souhaitée. Ce refactor présente plusieurs avantages, notamment une maintenabilité améliorée, tout en mettant également en évidence les compromis potentiels impliqués dans de tels changements.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!