TLDR;

O padrão chamado “type object” substitui a hierarquia de classes ao representar cada variação como um objeto contendo os dados do plano. Subclasses são adequadas para poucas variações estáveis, dicionários funcionam quando a configuração é simples, e o type object é indicado quando há muitas variações e necessidade de manter lógica separada dos dados. Ao usar objetos do tipo SubscriptionPlan que armazenam as configurações e são referenciados pelas assinaturas, elimina‑se a necessidade de criar uma classe distinta para cada tipo de plano.

Resumo

O vídeo explica como modelar diferentes planos de assinatura em uma aplicação SaaS usando Python e compara três abordagens distintas. Primeiro, demonstra a implementação tradicional com subclasses: há uma classe base Subscription e subclasses como FreeSubscription, ProSubscription e BusinessSubscription, cada uma apenas inicializando valores específicos (preço mensal, número máximo de projetos, armazenamento, recursos disponíveis). Embora funcione, esse modelo gera uma explosão de classes à medida que novos planos (startup, education, enterprise, etc.) são criados, tornando a manutenção difícil e espalhando a configuração dos planos por toda a hierarquia.

Em seguida, apresenta a alternativa de eliminar as subclasses e armazenar todas as informações dos planos em dicionários ou outras estruturas de dados, usando um enum PlanType para identificar o plano escolhido. Essa solução simplifica a adição de novos planos – basta inserir mais entradas nos dicionários – mas acumula grandes volumes de configuração dispersa, o que pode provocar erros (por exemplo, ausência de preço mensal) e dificultar a validação.

Por fim, introduz o padrão type object: cria‑se uma classe SubscriptionPlan que representa um plano como objeto contendo todas as suas propriedades; a classe Subscription passa a referenciar um objeto SubscriptionPlan em vez de um enum. Assim, preserva‑se a clareza orientada a objetos, centralizando a definição de cada plano em instâncias distintas e permitindo fácil extensão sem proliferar subclasses. O apresentador ressalta que nenhuma das abordagens é intrinsecamente “má”; a escolha depende da complexidade dos planos, frequência de mudanças e necessidades de manutenção do código.