Maison  >  Article  >  développement back-end  >  Comment supprimer une déclaration d'ami sans compromettre le design ?

Comment supprimer une déclaration d'ami sans compromettre le design ?

Patricia Arquette
Patricia Arquetteoriginal
2024-11-04 13:20:30934parcourir

How to Remove a Friend Declaration Without Compromising Design?

Comment supprimer une déclaration d'ami tout en préservant le design

L'utilisation du mot-clé "friend" dans la conception orientée objet peut créer des dépendances étroites et entraver la maintenabilité. Cet article propose une approche complète pour supprimer une déclaration d'ami tout en préservant la conception globale du système.

Contexte du problème :

Considérons un scénario dans lequel deux classes, ClassA et ClassAAccessor, ayez une relation amicale. ClassA représente une ressource partagée avec des méthodes protégées, tandis que ClassAAccessor sert d'aide pour gérer l'accès à cette ressource. La relation d'amitié entre ClassA et ClassAAccessor permet à ClassAAccessor d'accéder directement aux méthodes protégées de ClassA.

Contraintes de conception :

Pour garantir une refactorisation appropriée, plusieurs contraintes sont définies :

  • L'interface publique de ClassAAccessor devrait rester inchangée.
  • Les opérations internes de ClassA devraient rester privées.
  • Les performances et la consommation de mémoire ne devraient pas être affectées de manière significative.

Étapes de refactoring :

Étape 1 : Introduire une interface abstraite

Extraire les opérations qui étaient auparavant accessibles via l'ami relation dans une interface distincte appelée InternalInterface. Refactorisez la relation entre ClassA et ClassAAccessor pour la rendre dépendante de cette interface plutôt que d'utiliser le mot-clé ami.

Étape 2 : Déplacer les opérations vers l'interface

Déplacer les opérations de ClassA à l'InterfaceInterne. Cela élimine la dépendance « d'appel » de ClassAAccessor directement à ClassA.

Étape 3 : Collez l'implémentation ensemble

Créez une variable membre privée dans ClassAAccessor qui pointe vers une instance de Interface interne. Introduisez une méthode dans ClassA qui permet de définir cette variable membre pour permettre à ClassAAccessor d'accéder aux opérations internes requises.

Exemple d'implémentation :

<code class="cpp">class ClassAAccessor {
public:
    ClassAAccessor(ClassA&amp; classA);
    void setInternalInterfaceRef(InternalInterface &amp; newValue) {
        internalInterfaceRef = &amp;newValue;
    }
private:  
    InternalInterface* internalInterfaceRef;
};

class ClassA : protected InternalInterface {
public:
    attachAccessor(ClassAAccessor &amp; accessor);
};</code>

Avantages de Refactoring :

  • Élimine la dépendance étroite entre ClassA et ClassAAccessor.
  • Garantit un accès privé aux opérations internes de ClassA.
  • Fournit une conception plus modulaire et plus maintenable .

Inconvénients du refactoring :

  • Complexité accrue dans la structure du code.
  • Possibilité d'une consommation de mémoire légèrement accrue en raison de la introduction d'interfaces supplémentaires.
  • Support UML limité pour les relations de généralisation protégées.

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn