Composição, herança e __slots__

É um contra tem um

Herança é atraente porque parece resolver reúso de código de graça: herde e ganhe os métodos da base. Mas ela cria um laço forte entre a classe filha e a mãe, e usada onde não cabe gera hierarquias confusas. A pergunta que orienta a decisão é simples e velha conhecida: o novo tipo é um subtipo do outro, ou apenas contém o outro? Se um Gato é um Animal, a herança modela bem: o gato realmente é um caso particular de animal. Mas se um Carro tem um Motor, herdar Carro de Motor seria absurdo, porque o carro não é um tipo de motor; ele tem um. Aí a relação certa é composição.

Composição na prática

Na composição, em vez de herdar, a classe guarda um objeto de outra como atributo e delega a ele o que for da sua alçada. O Carro tem um Motor guardado em self.motor e, quando precisa ligar, chama self.motor.ligar(). A vantagem é o baixo acoplamento: o carro depende apenas da interface do motor, não da sua estrutura interna, e você pode trocar o tipo de motor sem reescrever o carro. É mais flexível que a herança, que amarra a filha à implementação da mãe. Por isso um conselho clássico de projeto é preferir composição a herança quando ambas parecem possíveis; a herança fica reservada aos casos claros de é um.

class Motor:
    def __init__(self, potencia):
        self.potencia = potencia

    def ligar(self):
        return f"motor de {self.potencia}cv ligado"

class Carro:
    def __init__(self, modelo, potencia):
        self.modelo = modelo
        self.motor = Motor(potencia)   # Carro TEM UM Motor (composicao)

    def ligar(self):
        return f"{self.modelo}: {self.motor.ligar()}"

c = Carro("Sedan", 120)
print(c.ligar())   # Sedan: motor de 120cv ligado

Carro compõe um Motor e delega a ele: baixo acoplamento, fácil de trocar o motor.

__slots__ e a economia de memória

O último recurso do módulo é uma otimização. Por padrão, cada instância no Python guarda seus atributos em um dicionário interno, o __dict__, o que dá muita flexibilidade: você pode acrescentar um atributo novo a um objeto a qualquer momento. Essa flexibilidade tem um custo de memória por instância, irrelevante para poucos objetos, mas pesado quando você cria milhões. O __slots__ é a resposta. Ao declarar __slots__ com a lista dos atributos permitidos, você diz ao Python para reservar espaço fixo para eles e dispensar o dicionário interno. O ganho de memória é substancial e, muitas vezes, o acesso aos atributos fica até um pouco mais rápido.

class PontoLivre:
    def __init__(self, x, y):
        self.x = x
        self.y = y

class PontoSlots:
    __slots__ = ("x", "y")   # so estes atributos, sem __dict__

    def __init__(self, x, y):
        self.x = x
        self.y = y

p = PontoSlots(1, 2)
print(p.x, p.y)     # 1 2  (funciona normalmente)
# p.z = 3           # AttributeError: nao esta em __slots__

__slots__ fixa os atributos e remove o __dict__ por instância, economizando memória.

A economia vem com um preço, e é justo conhecê-lo antes de sair usando __slots__ em tudo. Como não há mais o dicionário interno, você não pode acrescentar atributos que não estejam na lista: tentar fazê-lo levanta um erro. Isso é ótimo quando você quer justamente travar a estrutura, mas atrapalha se o seu design conta com atributos dinâmicos. Há também sutilezas com herança e com alguns recursos que esperam o __dict__. A regra prática é: use __slots__ quando tiver muitas instâncias de uma classe simples e de estrutura fixa, e o consumo de memória for medido como um problema real. Fora desse cenário, a flexibilidade padrão costuma valer mais que a economia.