Antwoord

Het sleutelwoord friend stelt een bepaalde functie of een andere klasse in staat om toegang te krijgen tot de private en protected leden van de klasse waarin friend is gedeclareerd. Friend-functies kunnen zowel globaal als methoden van andere klassen zijn. Deze constructie maakt het mogelijk om functies te implementeren die toegang nodig hebben tot de interne toestand van een klasse, maar die logisch niet verbonden zijn met de interface van die klasse.

Het wordt aanbevolen om friend te gebruiken:

• Voor de implementatie van vergelijkingsoperators, wiskundige operators (operator<<, operator==, enzovoort), wanneer functies toegang moeten hebben tot de private leden van twee objecten tegelijk.
• Wanneer een externe functie logisch geen methode van de klasse is, maar een deel van het gedrag ervan moet implementeren.
• Voor een hechte koppeling van samenwerkende klassen (bijvoorbeeld toegang tot private gegevens van naburige interne objecten).

Let op:

• Het toekennen van friend-functies opent toegang tot private gegevens en schendt de encapsulatie.
• Misbruik van friend kan leiden tot toegenomen koppeling in de code en verzwakking van de veiligheid.

Voorbeeld:

class Box {
    int width;
public:
    Box(int w): width(w) {}
    friend void printWidth(const Box &b);
};

void printWidth(const Box &b) {
    std::cout << b.width << std::endl;
}

Misleidende vraag

Vraag: Kan een friend-functie virtueel zijn?
Veelvoorkomend antwoord: Ja, want friend is een functiemodificator.
Juiste antwoord: Nee, friend-functies kunnen niet virtueel zijn, omdat ze geen leden van de klasse zijn!

Voorbeeld:

class Example {
    friend virtual void foo(); // Compilatiefout: virtual is niet van toepassing op friend
};

Voorbeelden van echte fouten door onwetendheid over de nuances van het onderwerp

---

Verhaal: Bij het ontwerpen van een matrixbibliotheek werden alle wiskundige operators friend-functies gemaakt voor snellere uitvoering, maar men vergat de ondersteuning van constantheid en opende overbodig toegang tot private leden. Later ontstond er een probleem — andere functies in het project wijzigden per ongeluk de interne toestand van Matrix.

---

---

Verhaal: In een bedrijfsysteem werden helperklassen vriend van elkaar gemaakt om toegang tot private leden te delen. Dit leidde tot cyclische afhankelijkheden — het toevoegen van een nieuwe functie vereiste veranderingen in alle gekoppelde klassen. De daaropvolgende refactor nam weken in beslag.

---

---

Verhaal: Voor gesloten tests werd besloten om de testklasse friend te maken van de productieklasse. Toen er verschillende sets unit-tests verschenen, werd het onmogelijk om te volgen welke private methoden daadwerkelijk werden gebruikt — de tests begonnen afhankelijk te worden van de interne implementatie, wat leidde tot een complexe onderhoud van de code.

---