Respuesta.

Las extensiones en Swift surgieron como un medio para ampliar tipos — tanto los estándar (por ejemplo, String, Array) como los personalizados — sin la necesidad de crear subclases o modificar el código fuente original. Esto permite agregar nuevos métodos, propiedades calculadas, conformidades a protocolos e incluso adherencia a protocolos, manteniendo la legibilidad y una arquitectura de código coherente.

El problema surge con el uso excesivo o desorganizado de extensiones: se puede perder rápidamente el control sobre el comportamiento original de los tipos, pueden surgir conflictos de nombres y es más complicado rastrear de dónde provienen las cosas, especialmente en proyectos grandes o al incluir bibliotecas de terceros.

La solución consiste en tener una estructura clara, organizar las extensiones por grupos semánticos, documentación explícita y evitar conflictos con nombres existentes, así como limitar el alcance si es necesario (por ejemplo, mediante fileprivate o internal).

Ejemplo de código:

extension String {
    var isEmail: Bool {
        return self.contains("@") && self.contains(".")
    }
    func trimmed() -> String {
        return trimmingCharacters(in: .whitespacesAndNewlines)
    }
}

Características clave:

Permite agregar nuevos métodos, propiedades y conformidades a protocolos sin acceso a los archivos fuente.
No soporta el almacenamiento de nuevas propiedades almacenadas — solo propiedades calculadas y funciones.
Puede ser limitado en alcance utilizando fileprivate/internal.

Preguntas capciosas.

¿Se puede agregar una propiedad almacenada a través de una extensión?

No, la extensión solo permite agregar propiedades calculadas y métodos. No se pueden agregar propiedades almacenadas a través de una extensión. Inténtalo — el compilador dará un error inmediatamente.

¿Qué sucederá si en dos extensiones diferentes se declaran métodos con el mismo nombre para un tipo en diferentes archivos?

Habrá un conflicto de nombres, y Swift no podrá resolver qué método llamar, y el error se manifestará en tiempo de compilación.

¿Pueden las extensiones implementar métodos privados que solo son visibles dentro de la extensión?

Sí, si se declara un método con private, solo será visible dentro de la propia extensión y de ese archivo en el que se declara (si se utiliza fileprivate).

extension Int {
    private func isEvenInternal() -> Bool {
        return self % 2 == 0
    }
    func publicCheckEven() -> Bool {
        return isEvenInternal()
    }
}

Errores típicos y anti-patrones

Anti-patrón: Agregar una gran cantidad de funciones de diferentes tipos en una sola extensión sin agrupamiento lógico.
Error: No respetar el alcance (por ejemplo, extensión pública para una función que utiliza detalles internos).
Conflictos de nombres al trabajar con bibliotecas o al escribir extensiones para un mismo tipo por diferentes desarrolladores, si no se acuerdan las áreas de trabajo.

Ejemplo de la vida real

** Caso negativo

En un gran proyecto, se agregan a String mediante extensiones métodos para todo — desde la validación de correos electrónicos hasta el análisis de JSON. Después de un año, nadie puede entender de dónde proviene cada método: los métodos colisionan en los nombres, alguien agrega una nueva función sin saber de la antigua, y rompe el comportamiento de los dependientes.

Ventajas:

Se añaden rápidamente nuevas funcionalidades sin tocar el tipo principal.

Desventajas:

Confusión, duplicación, errores, comportamiento impredecible, dificultad en el mantenimiento.

** Caso positivo

El equipo utiliza extensiones para grupos lógicos: una extensión separada para validaciones, otra para formateo, con ayudantes privados internos. Todos los métodos están documentados, el uso de nuevos métodos se discute, hay revisión de código.