Super() vs Nom de la Classe Pare: Quin És el Camí Correcte en Python?

Si has treballat amb herència en Python, t’has trobat davant d’aquesta disjuntiva: utilitzar super() o cridar directament la classe pare amb NomClasse.__init__()? La decisió va més enllà de la preferència personal — afecta la mantenibilitat, l’escalabilitat i fins i tot la correcta execució dels teus programes quan la complexitat creix.

(Imatge: Diagrama comparatiu mostrant la diferència entre cridades directes i la delegació dinàmica de super())

La Disjuntiva: Rigidesa vs Flexibilitat

Enfocament Tradicional: Crida Explícita

class Vehicle:
    def __init__(self, marca):
        self.marca = marca

class Cotxe(Vehicle):
    def __init__(self, marca, model):
        Vehicle.__init__(self, marca)  # Crida explícita
        self.model = model

Aquí, Cotxe està fortament lligat a Vehicle. Si demà decideixes afegir una classe intermèdia VehicleMotoritzat, el codi de Cotxe deurà ser modificat manualment — una recepta perfecta per errors i feina duplicada.

Enfocament Modern: Super() com a Delegat Intel·ligent

class Cotxe(Vehicle):
    def __init__(self, marca, model):
        super().__init__(marca)  # Delegació dinàmica
        self.model = model

super() actua com un mediador intel·ligent que pregunta: “D’acord, segons l’ordre d’herència actual (MRO), quin és el següent a la cadena que ha d’executar aquest mètode?”

El Cor del Problema: El MRO (Method Resolution Order)

Python utilitza un algorisme complex (C3 linearization) per determinar l’ordre en què es busquen els mètodes en herència múltiple. super() respecta aquest ordre, mentre que la crida directa l’ignora.

Visualització del MRO:
ClasseD → ClasseB → ClasseC → ClasseA → object

Quan ClasseD crida super(), segueix aquesta cadena automàticament. Amb crida directa, hauries de saber i codificar manualment aquesta jerarquia.

Cas Pràctic: Quan la Diferència és Crucial

Imagina que desenvolupes una biblioteca de formes geomètriques:

class Figura:
    def __init__(self, color):
        self.color = color
        print(f"Figura inicialitzada amb color {color}")

class Polygon(Figura):
    def __init__(self, color, costats):
        super().__init__(color)  # Correcte: crida Figura.__init__
        self.costats = costats

class Triangle(Polygon):
    def __init__(self, color):
        super().__init__(color, 3)  # Correcte: crida Polygon.__init__

Si després afegeixes class FiguraAnimada(Figura) i fas que Polygon en hereti, el codi amb super() continua funcionant perfectament. El codi amb crides explícites trencaria.

Les Excepcions: Quan NO Utilitzar super()

Hi ha situacions on la crida explícita té sentit:

1. Quan necessites evitar completament la cadena d’herència
2. En casos molt específics d’herència múltiple amb diamant on el comportament estàndard no és el desitjat
3. En codi legacy que ja utilitza aquest patró consistentment

Recomanació Final

Per a nous projectes i codi que esperes que evolucioni, super() és generalment la millor opció. Proporciona:

• Mantenibilitat: Resistència als canvis d’estructura
• Consistència: Segueix les convencions modernes de Python
• Seguretat: Evita errors subtils en herència múltiple
• Llegibilitat: Sintaxi més clara i concisa

Els casos d’ús per a crides explícites són cada cop més estranys i justificats només en circumstàncies molt específiques.

La pròxima vegada que escriguis __init__ en una classe filla, recorda: super() no és només una alternativa — és una inversió en el futur del teu codi.