roteiro da aula

O que vamos aprender hoje

ponte com a aula 20

De onde paramos — criacionais montam o elenco

• 🏭 Na aula 20 vimos os criacionais: Singleton (QUANTAS instâncias existem) e Factory (QUAL classe criar). Eles cuidam de COMO os objetos nascem.
• 💬 Hoje, a segunda família GoF — os comportamentais: depois que os objetos existem, COMO eles conversam e dividem responsabilidades entre si.
• 🎭 A imagem que ajuda: os criacionais montam o elenco (decidem quem entra em cena e quantos); os comportamentais ensaiam a peça (decidem como os atores interagem).
• 🧱 Mesmas ferramentas de sempre: ABC e @abstractmethod (10), polimorfismo (09), composição (05). Não é Python novo — é arranjo novo do que você já sabe.

comportamentais · panorama

Os dois padrões de hoje, em uma frase cada

• 📣 Observer (Observador): quando algo muda, AVISA vários interessados de uma vez. Um Subject → muitos observers. É a base de eventos e notificações.
• 🔀 Strategy (Estratégia): troca o COMO — o algoritmo — sem mudar quem chama. Um Contexto → uma estratégia trocável. É a base de "escolher o cálculo em runtime".
• 🧩 Os dois são comportamentais e vivem do mesmo tripé: ABC pro contrato, polimorfismo pra chamar sem isinstance, e composição pra guardar os colaboradores. Vamos pela dor de cada um.

observer · definição

O que é o Observer

• 📡 Observer é um padrão comportamental: um objeto (o Subject) mantém uma lista de interessados (os Observers) e, ao mudar de estado, AVISA todos eles.
• 1️⃣ É uma relação de UM para MUITOS: o Subject não conhece cada observer pelo nome — ele só percorre a lista e chama o mesmo método em cada um. Quem reage faz a própria coisa.
• 🔌 Observer novo? inscrever() e pronto. O Subject não muda. É o oposto de ter os avisos chumbados dentro do código que dispara a mudança.

observer · o problema

O problema do Observer: avisos chumbados no código

• 📺 Um canal de vídeos publica um vídeo novo e precisa avisar os inscritos. A solução ingênua: dentro de publicar(), chamar enviar_email(ana), enviar_push(bruno)... um a um, na mão.
• 🌿 Cada inscrito novo vira mais uma linha dentro de publicar(); cada forma de aviso vira mais um if/elif. O método que devia só "publicar" sabe demais sobre QUEM avisar e COMO.
• 🔗 O resultado é acoplamento: o Subject conhece cada interessado pelo nome. Mudou a lista de inscritos? Mexe no publicar(). Queríamos que ele só avisasse — sem saber quem está ouvindo.

observer · ancorando a ideia

Analogia: o grupo de avisos da escola

• 📨 Pense no grupo de avisos da escola. A secretaria manda UMA mensagem — "aula cancelada amanhã" — e TODO mundo no grupo recebe de uma vez. Ela não manda um por um.
• ➕ Entrou um responsável novo? Ele entra no grupo e passa a receber. Saiu? Sai do grupo e para de receber. A secretaria não muda nada no jeito de mandar a mensagem.
• 📡 Observer é exatamente isso no código: o Subject (a secretaria) tem uma lista de inscritos e dispara um aviso pra todos; cada inscrito decide o que fazer com ele.

observer · o problema

Antes e depois do Observer

O mesmo canal, dois jeitos de notificar: cada aviso chumbado dentro de publicar() (o problema) e uma lista de inscritos que recebe o aviso por polimorfismo (o Observer).

def publicar(self, video):
    # cada inscrito chumbado aqui dentro
    enviar_email("Ana", video)
    enviar_push("Bruno", video)
    # inscrito novo? mais uma linha aqui.
    # forma de aviso nova? mais um if.
    # o publicar() conhece cada um pelo nome.

def publicar(self, video):
    # só percorre a lista e avisa
    for inscrito in self.inscritos:
        inscrito.atualizar(video)
    # inscrito novo? só inscrever().
    # o publicar() NÃO conhece ninguém
    # pelo nome — só chama atualizar().

observer · o código

Observer em Python: Canal e Inscritos

Uma ABC Inscrito (aula 10) com o método atualizar() abstrato — o contrato de "sei reagir a um aviso". O Canal é o Subject: guarda a lista de inscritos e, ao publicar(), percorre e avisa todos por polimorfismo (aula 09).

from abc import ABC, abstractmethod

class Inscrito(ABC):
    @abstractmethod
    def atualizar(self, video):
        pass

class Email(Inscrito):
    def __init__(self, nome):
        self.nome = nome
    def atualizar(self, video):
        print(f"[E-mail] {self.nome}: novo vídeo '{video}'")

class Push(Inscrito):
    def __init__(self, nome):
        self.nome = nome
    def atualizar(self, video):
        print(f"[Push] {self.nome}: saiu '{video}'!")

class Canal:                          # o Subject
    def __init__(self, nome):
        self.nome = nome
        self.inscritos = []           # composição: o Canal COMPÕE inscritos
    def inscrever(self, inscrito):
        self.inscritos.append(inscrito)
    def publicar(self, video):
        print(f"== {self.nome} publicou: {video} ==")
        for inscrito in self.inscritos:
            inscrito.atualizar(video)  # avisa todos, sem saber o tipo

canal = Canal("DevTube")
canal.inscrever(Email("Ana"))
canal.inscrever(Push("Bruno"))
canal.publicar("POO em Python")

observer · o código

Saída no terminal

Rodando o canal.py, um único publicar() dispara o aviso para os dois inscritos:

== DevTube publicou: POO em Python ==
[E-mail] Ana: novo vídeo 'POO em Python'
[Push] Bruno: saiu 'POO em Python'!

observer · na UML

O Observer em UML

O Canal e os inscritos que acabamos de codar, desenhados como caixas de classe (a notação da aula 19): o Subject que compõe uma lista de Observers.

observer · onde você já viu (e vai ver)

Ecossistema: os callbacks de GUI SÃO Observer

• 🖱️ Toda interface gráfica é feita de Observer. Quando você liga uma função a um botão — button.config(command=ao_clicar) — você está REGISTRANDO um observer no botão.
• 🔔 Quando o botão é clicado, ele AVISA: chama o ao_clicar() que você registrou. O botão é o Subject; a sua função é o observer. No navegador é o mesmo: addEventListener("click", ...).
• 🪟 Por isso o Observer é a espinha dorsal da GUI de quarta-feira: ligar uma função a um botão = inscrever um observer. O padrão de hoje é o que vai fazer a interface da aula 22 reagir aos cliques.

observer · amarrando com a POO

Conexão: o Observer só junta o que você já sabe

• 🧬 ABC + @abstractmethod (aula 10): Inscrito é o contrato — todo observer PRECISA ter atualizar(). O Subject confia nesse contrato pra avisar qualquer um.
• 🎭 Polimorfismo (aula 09): o for inscrito in ...: inscrito.atualizar(video) chama o método certo de cada subclasse, sem isinstance, sem if/elif.
• 🧱 Composição (aula 05): o Canal COMPÕE uma lista de inscritos — tem-um, não é-um. A relação Subject↔Observers é composição pura.
• 📋 Lista de objetos (aula 18): self.inscritos é uma lista que você percorre. Tudo o que muda em relação à aula 20 é a INTENÇÃO: lá a gente criava objetos; aqui eles se comunicam.

observer · quando NÃO usar

Armadilha: observers que vazam (e nunca saem da lista)

O erro mais comum: inscrever e nunca remover. A lista só cresce, observers "mortos" continuam recebendo aviso. A defesa é ter um cancelar() que tira da lista.

# só inscreve, nunca remove:
loja.inscrever("Ana")
loja.inscrever("Bruno")
# Ana saiu do site, mas continua
# na lista — vai receber avisos
# pra sempre. A lista só CRESCE.

def cancelar(self, obs):
    self.inscritos.remove(obs)

loja.inscrever("Ana")
loja.inscrever("Bruno")
loja.cancelar("Ana")
loja.avisar_promocao("Notebook")
# Bruno: promoção de Notebook!
# (só Bruno — Ana saiu da lista)

strategy · definição

O que é o Strategy

• 🔀 Strategy é um padrão comportamental: cada algoritmo vira uma classe própria com um método comum, e um objeto (o Contexto) guarda a estratégia ativa e DELEGA o trabalho a ela.
• 🎛️ Você troca o COMO — o algoritmo — em tempo de execução, só trocando o objeto de estratégia. Quem chama (o Contexto) não muda; muda o objeto pra quem ele delega.
• 📦 Algoritmo novo? Uma classe nova de estratégia. O Contexto continua igual: ele só sabe que a estratégia tem o método certo e o chama. Encapsula cada cálculo no seu próprio objeto.

strategy · o problema

O problema do Strategy: o if/elif de algoritmos

• 🛒 Um carrinho calcula o total com desconto. A solução ingênua: if tipo == "black": total *= 0.7 elif tipo == "cupom": total -= 15... tudo dentro de calcular_total().
• 🌿 Cada promoção nova é mais um elif. O calcular_total() incha: vira um emaranhado de regras misturadas, e mexer numa promoção arrisca quebrar as outras.
• 🎯 O que a gente queria: cada regra de desconto morando no SEU próprio objeto, e o carrinho só DELEGANDO o cálculo pra estratégia ativa — trocável a qualquer momento. Esse é o trabalho do Strategy.

strategy · ancorando a ideia

Analogia: o app de rotas escolhendo o trajeto

• 🗺️ Pense no Waze. O destino é o MESMO, mas você escolhe a estratégia de rota: "mais rápida", "evitar pedágio", "a pé". Cada uma é um algoritmo diferente de calcular o caminho.
• 🔀 Você troca a estratégia no meio do caminho e o app recalcula — sem trocar de app, sem mudar o destino. O app DELEGA o cálculo do trajeto à estratégia que você escolheu.
• 🎛️ Strategy é esse seletor no código: o Contexto (o app) guarda a estratégia ativa (o tipo de rota) e delega a ela. Trocar o COMO é só trocar o objeto da estratégia.

strategy · o problema

Antes e depois do Strategy

O mesmo carrinho, dois jeitos de aplicar desconto: um if/elif que incha (o problema) e cada regra num objeto trocável a que o carrinho delega (o Strategy).

def total_final(self):
    if self.tipo == "black":
        return self.total * 0.70
    elif self.tipo == "cupom":
        return self.total - 15.00
    elif self.tipo == "nenhum":
        return self.total
    # promoção nova? mais um elif aqui.

def total_final(self):
    # delega o cálculo à estratégia ativa
    return self.desconto.calcular(self.total)

# trocar o COMO em runtime:
carrinho.desconto = DescontoBlackFriday()
# promoção nova? uma CLASSE nova.
# o total_final() não muda.

strategy · o código

Strategy em Python: Carrinho e Descontos

Uma ABC Desconto (aula 10) com calcular(valor) abstrato — o contrato comum. Cada promoção é uma subclasse. O Carrinho é o Contexto: guarda a estratégia ativa (self.desconto) e DELEGA a ela. Trocar a estratégia em runtime é só reatribuir o atributo.

from abc import ABC, abstractmethod

class Desconto(ABC):
    @abstractmethod
    def calcular(self, valor):
        pass

class SemDesconto(Desconto):
    def calcular(self, valor):
        return valor

class DescontoBlackFriday(Desconto):
    def calcular(self, valor):
        return valor * 0.70

class DescontoCupom(Desconto):
    def calcular(self, valor):
        return valor - 15.00

class Carrinho:                       # o Contexto
    def __init__(self, total, desconto):
        self.total = total
        self.desconto = desconto      # composição: COMPÕE a estratégia ativa
    def total_final(self):
        return self.desconto.calcular(self.total)  # DELEGA à estratégia

carrinho = Carrinho(100.00, SemDesconto())
print(f"Sem desconto:  R$ {carrinho.total_final():.2f}")
carrinho.desconto = DescontoBlackFriday()   # troca o COMO em runtime
print(f"Black Friday:  R$ {carrinho.total_final():.2f}")
carrinho.desconto = DescontoCupom()         # troca de novo
print(f"Cupom:         R$ {carrinho.total_final():.2f}")

strategy · o código

Saída no terminal

Rodando o carrinho.py, o MESMO carrinho devolve três totais diferentes — só trocando a estratégia entre as chamadas:

Sem desconto:  R$ 100.00
Black Friday:  R$ 70.00
Cupom:         R$ 85.00

strategy · na UML

O Strategy em UML

O Carrinho e os descontos que acabamos de codar: o Contexto que compõe UMA estratégia trocável de uma hierarquia de algoritmos.

strategy · onde você já viu (sem saber o nome)

Ecossistema: vocês já usaram Strategy na aula 18

O sorted(lista, key=...) da aula 18 é Strategy puro. A função que você passa em key= É a estratégia (o algoritmo de ordenação); o sorted é o Contexto que delega a ela. Trocar a key é trocar a estratégia.

produtos = [
    {"nome": "Teclado", "preco": 120},
    {"nome": "Mouse", "preco": 80},
    {"nome": "Monitor", "preco": 950},
]

# a key É a estratégia; o sorted é o Contexto que delega a ela
por_preco = sorted(produtos, key=lambda p: p["preco"])
por_nome = sorted(produtos, key=lambda p: p["nome"])

print([p["nome"] for p in por_preco])   # ['Mouse', 'Teclado', 'Monitor']
print([p["nome"] for p in por_nome])    # ['Monitor', 'Mouse', 'Teclado']

strategy · variação pythônica

Strategy mais leve: a estratégia pode ser só uma função

Em Python, quando a estratégia não tem estado, ela pode ser apenas uma FUNÇÃO passada como valor (aula 18) — sem precisar de uma classe inteira. O Contexto recebe a função e a chama.

def black_friday(valor):
    return valor * 0.70

def total_final(valor, estrategia):
    return estrategia(valor)        # delega à função-estratégia

print(f"R$ {total_final(100.0, black_friday):.2f}")   # R$ 70.00

strategy · amarrando com a POO

Conexão: o Strategy só junta o que você já sabe

• 🧬 ABC + @abstractmethod (aula 10): Desconto é o contrato — toda estratégia PRECISA ter calcular(). O Contexto confia nesse contrato pra delegar a qualquer uma.
• 🎭 Polimorfismo (aula 09): self.desconto.calcular(self.total) chama o método certo da estratégia ativa, sem isinstance. Mesma chamada, resultados diferentes.
• 🧱 Composição (aula 05): o Carrinho COMPÕE a estratégia — tem-uma, trocável. E funções como valor (aula 18): a estratégia pode ser só uma função.
• 🏭 Contraste com a aula 20: a Factory escolhe qual objeto CRIAR; o Strategy escolhe qual algoritmo USAR num objeto que já existe. Criar ≠ comportar-se.

strategy · quando NÃO usar

Armadilha: nem toda variação vira Strategy

• 🪶 Se o cálculo NUNCA varia — é sempre o mesmo —, não crie uma hierarquia de estratégias pra um if que não existe. Strategy é pra QUANDO o algoritmo precisa trocar.
• ⚖️ Se a estratégia não tem estado, em Python uma FUNÇÃO basta (s23). Não suba pra classe só por cerimônia — uma classe vazia que só embrulha um cálculo é over-engineering.
• 🚫 Não confunda com Observer: Strategy tem UMA estratégia ativa por vez e DELEGA a ela. Observer tem MUITOS interessados e AVISA todos. Um delega; o outro notifica.

fixando os dois

A frase-âncora: Observer vs Strategy

Os dois são comportamentais e vivem de ABC + polimorfismo + composição. A diferença é a INTENÇÃO. Grave: Observer = quando algo muda, AVISA vários; Strategy = troca o COMO sem mudar quem chama.

Quando algo muda, AVISA vários
interessados de uma vez.

1 Subject  →  MUITOS observers
Mecanismo: uma LISTA + notificar
(for obs: obs.atualizar(...))

Exemplo: Canal avisa inscritos;
cliques de botão na GUI.

Troca o COMO — o algoritmo —
sem mudar quem chama.

1 Contexto  →  1 estratégia trocável
Mecanismo: um ATRIBUTO + delegar
(self.estrategia.calcular(...))

Exemplo: Carrinho delega o desconto;
sorted(key=...) da aula 18.

ao vivo · vamos construir juntos

Exercício ao Vivo: um pedido com os dois padrões

Partindo do diagrama do próximo slide, a gente implementa juntos um pedido de e-commerce que usa Strategy (pra calcular o frete por estratégia trocável) e Observer (pra avisar os interessados quando o status muda). Acompanhem a tradução de cada parte pra código, camada por camada.

ao vivo · vamos construir juntos

O diagrama do nosso pedido

Partimos deste diagrama. Leia as caixas e os estereótipos — e nos próximos slides a gente traduz cada parte pra código, camada por camada.

resolução · camada 1

A Strategy: Frete (ABC) e as subclasses

Começamos pela estratégia de frete: a ABC Frete com calcular(peso) abstrato e as duas formas de cobrar. É o triângulo △ da esquerda do diagrama virando código.

from abc import ABC, abstractmethod

# Camada 1: Strategy — cálculo de frete (trocável)
class Frete(ABC):
    @abstractmethod
    def calcular(self, peso):
        pass

class FreteNormal(Frete):
    def calcular(self, peso):
        return peso * 2.00

class FreteExpresso(Frete):
    def calcular(self, peso):
        return peso * 2.00 + 20.00

resolução · camada 2

Os Observers: Observador (ABC) e as subclasses

Agora os interessados: a ABC Observador com atualizar(pedido, status) abstrato, e os dois que vão reagir quando o status mudar. É o triângulo △ da direita do diagrama.

# Camada 2: Observer — os interessados no status
class Observador(ABC):
    @abstractmethod
    def atualizar(self, pedido, status):
        pass

class PainelLojista(Observador):
    def atualizar(self, pedido, status):
        print(f"[Painel] Pedido {pedido} -> {status}")

class SMSCliente(Observador):
    def atualizar(self, pedido, status):
        print(f"[SMS] Seu pedido {pedido} agora está: {status}")

resolução · camada 3

O Pedido: Contexto (Strategy) + Subject (Observer)

A última camada junta os dois papéis num objeto só. O Pedido COMPÕE um frete (a estratégia, a que ele delega) e uma lista de observadores (os interessados, que ele avisa).

# Camada 3: o Pedido é Contexto (Strategy) E Subject (Observer)
class Pedido:
    def __init__(self, codigo, peso, frete):
        self.codigo = codigo
        self.peso = peso
        self.frete = frete            # Strategy: a estratégia ativa
        self.observadores = []        # Observer: a lista de interessados
    def inscrever(self, obs):
        self.observadores.append(obs)
    def valor_frete(self):
        return self.frete.calcular(self.peso)   # DELEGA ao frete (Strategy)
    def mudar_status(self, status):
        for obs in self.observadores:           # AVISA todos (Observer)
            obs.atualizar(self.codigo, status)

resolução · o código completo

Tudo junto: a resolução completa

As três camadas num arquivo só — é exatamente isto que você roda. Repare como Strategy e Observer convivem: o pedido delega o frete à estratégia ativa e avisa os observadores quando o status muda.

from abc import ABC, abstractmethod

# Camada 1: Strategy — cálculo de frete
class Frete(ABC):
    @abstractmethod
    def calcular(self, peso):
        pass

class FreteNormal(Frete):
    def calcular(self, peso):
        return peso * 2.00

class FreteExpresso(Frete):
    def calcular(self, peso):
        return peso * 2.00 + 20.00

# Camada 2: Observer — os interessados no status
class Observador(ABC):
    @abstractmethod
    def atualizar(self, pedido, status):
        pass

class PainelLojista(Observador):
    def atualizar(self, pedido, status):
        print(f"[Painel] Pedido {pedido} -> {status}")

class SMSCliente(Observador):
    def atualizar(self, pedido, status):
        print(f"[SMS] Seu pedido {pedido} agora está: {status}")

# Camada 3: o Pedido é Contexto (Strategy) E Subject (Observer)
class Pedido:
    def __init__(self, codigo, peso, frete):
        self.codigo = codigo
        self.peso = peso
        self.frete = frete
        self.observadores = []
    def inscrever(self, obs):
        self.observadores.append(obs)
    def valor_frete(self):
        return self.frete.calcular(self.peso)
    def mudar_status(self, status):
        for obs in self.observadores:
            obs.atualizar(self.codigo, status)

# Tudo junto: Strategy delega o frete, Observer avisa o status
pedido = Pedido("A-100", 3.0, FreteNormal())
pedido.inscrever(PainelLojista())
pedido.inscrever(SMSCliente())

print(f"Frete normal: R$ {pedido.valor_frete():.2f}")
pedido.frete = FreteExpresso()                # troca a estratégia em runtime
print(f"Frete expresso: R$ {pedido.valor_frete():.2f}")

pedido.mudar_status("ENVIADO")                 # avisa todos os observadores

resolução · saída esperada

A saída no terminal

Rodando o pedido.py, é isto que aparece no terminal:

Frete normal: R$ 6.00
Frete expresso: R$ 26.00
[Painel] Pedido A-100 -> ENVIADO
[SMS] Seu pedido A-100 agora está: ENVIADO

recapitulando

Glossário rápido de hoje

O que dominamos hoje

• ✓
  Sei o que distingue a família dos padrões comportamentais dos criacionais (aula 20): comunicação e responsabilidade vs. criação.
• ✓
  Explico o problema que o Observer resolve: avisos chumbados e acoplados dentro do código, em vez de uma lista de interessados.
• ✓
  Implemento um Observer: um Subject com lista de observers + um método que percorre e chama atualizar() em todos, por polimorfismo, e um cancelar() pra evitar vazamento.
• ✓
  Reconheço que os callbacks de GUI são Observer: ligar uma função a um botão (command=) é inscrever um observer — a base da interface da aula 22.
• ✓
  Explico o problema que o Strategy resolve: o if/elif de algoritmos inchando um método, em vez de cada algoritmo num objeto trocável.
• ✓
  Implemento um Strategy: uma ABC de algoritmo + um Contexto que guarda a estratégia ativa e DELEGA a ela, trocando o COMO em runtime — e sei que o sorted(key=) da aula 18 já era Strategy.
• ✓
  Sei a frase-âncora dos dois: Observer = quando algo muda, AVISA vários interessados; Strategy = troca o COMO (o algoritmo) sem mudar quem chama.

exercícios

Mãos à obra: os exercícios

Quatro exercícios em três níveis: um de Observer, um de Strategy, um de Observer a partir de um diagrama, e um desafio que junta os dois padrões. Cada um é INDIVIDUAL e termina em arquivo entregável. Comece em sala; termine o que faltar em casa. Mire pelo menos um de cada nível.

exercício 3 · do diagrama ao código

O diagrama do Exercício 3 — Leilão

Este é o diagrama do exercício 3. Leia a relação Subject↔Observers — o Leilao e os Participantes — e traduza cada parte pra código Python.

Antes de entregar: confira

• ✓
  Meu Observer prova que VÁRIOS são avisados com um único disparo, e tem cancelar()/remover pra não vazar observers da lista.
• ✓
  Meu Strategy troca o algoritmo SEM mudar o Contexto: a mesma operação dá resultados diferentes só trocando a estratégia ativa.
• ✓
  Os dois contratos (Observer e Strategy) são ABCs com @abstractmethod, e as subclasses os implementam.
• ✓
  O uso é polimórfico: percorro a lista / delego à estratégia sem nenhum isinstance ou if por tipo.
• ✓
  Os nomes, strings e comentários estão em PT-BR, e o arquivo .py roda do começo ao fim sem erro.
• ✓
  No desafio, entreguei o diagrama em PDF E o código .py, com 1 Subject+observers e 1 Contexto+estratégia, e o diagrama bate com o que implementei.