Respuesta

La palabra clave friend permite a una función o a otra clase tener acceso a los miembros privados y protegidos de la clase donde se declara friend. Las funciones friend pueden ser tanto globales como métodos de otras clases. Esta construcción permite implementar funciones que requieren acceso al estado interno de una clase, pero que lógicamente no están relacionadas con la interfaz de esa clase.

Se recomienda usar friend:

• Para implementar operadores de comparación, operadores matemáticos (operator<<, operator==, etc.), cuando las funciones deben tener acceso a miembros privados de dos objetos.
• Cuando una función externa no es lógicamente un método de la clase, pero debe implementar parte de su comportamiento.
• Para una estrecha relación entre clases que trabajan juntas (por ejemplo, acceso a datos privados de objetos internos vecinos).

Advertencia:

• Asignar funciones friend abre el acceso a datos privados y rompe la encapsulación.
• El abuso de friend puede llevar a un aumento de la cohesión en el código y debilitar la seguridad.

Ejemplo:

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;
}

Pregunta capciosa

Pregunta: ¿Puede ser una función friend virtual?
Respuesta común: Sí, porque friend es un modificador de función.
Respuesta correcta: No, las funciones friend no pueden ser virtuales, ¡porque no son miembros de la clase!

Ejemplo:

class Example {
    friend virtual void foo(); // Error de compilación: virtual no se aplica a friend
};

Ejemplos de errores reales debido a la falta de conocimiento de los matices del tema

---

Historia: Al diseñar una biblioteca de matrices, se hicieron todos los operadores aritméticos funciones friend para acelerar, pero se olvidaron del soporte de la constancia y abrieron en exceso el acceso a miembros privados. Más tarde surgió un problema: en el proyecto, otras funciones cambiaron accidentalmente el estado interno de Matrix.

---

---

Historia: En un sistema corporativo, las clases auxiliares se convirtieron en friends entre sí para compartir acceso a miembros privados. Esto llevó a dependencias cíclicas: agregar una nueva función requería cambiar todas las clases relacionadas. La posterior refactorización tomó semanas.

---

---

Historia: Para pruebas cerradas, se decidió hacer que una clase de prueba fuera friend de la clase de producción. Cuando aparecieron varios conjuntos de pruebas unitarias, rastrear qué métodos privados realmente se usaban se volvió imposible; las pruebas comenzaron a depender de la implementación interna, lo que llevó a un mantenimiento complicado del código.

---