NOTAS DO PROFESSOR
- Enfatizar: genérico não significa "vago". Significa escrito para variar de forma controlada.
- Erro comum: confundir código genérico com código copiado e colado com pequenas alterações. É o oposto.
- Analogia: uma tomada universal serve vários tipos de ficha. O código genérico é a "tomada universal" do programa.
NOTAS DO PROFESSOR
- Ligar diretamente ao critério de desempenho "evitando complexidades desnecessárias".
- Erro comum: generalizar cedo demais, criando abstrações para casos que nunca acontecem.
- Pergunta à turma: dão um exemplo do dia a dia em que reutilizaram algo em vez de repetir?
NOTAS DO PROFESSOR
- Enfatizar que JavaScript é multi-paradigma: é isso que torna possível escrever código genérico de várias formas.
- Erro comum: achar que "orientado a objetos" é a única forma correta de programar.
- Exemplo: mostrar a mesma tarefa (somar uma lista) em estilo imperativo e em estilo funcional (reduce).
NOTAS DO PROFESSOR
- Voltar a este slide no Bloco 5, quando se aprofunda tipagem dinâmica.
- Erro comum: pensar que "interpretada" é sempre pior que "compilada". São escolhas com vantagens diferentes.
- Perguntar: porque é que a web escolheu uma linguagem interpretada? (não precisa de instalação, corre em qualquer browser).
NOTAS DO PROFESSOR
- Este é o exemplo âncora da genericidade: a mesma função serve dois tipos de dados diferentes.
- Erro comum: escrever ordenarNumeros() e ordenarTexto() separadas. Perguntar à turma o que têm em comum.
- Introduzir a ideia de "função como parâmetro" sem ainda a formalizar (volta em frameworks).
NOTAS DO PROFESSOR
- Pedir à turma para classificar exemplos: idade (primitivo, número), lista de alunos (composto, array de objetos).
- Erro comum: usar um array quando o problema pede acesso rápido por chave (devia ser objeto/mapa).
- Ligar ao bloco seguinte: as estruturas de dados são o "contentor" onde os algoritmos genéricos trabalham.
NOTAS DO PROFESSOR
- Pedir à turma exemplos de cada estrutura fora da informática (fila do supermercado = queue, pilha de pratos = stack).
- Erro comum: usar sempre array para tudo. Perguntar quando um Set ou um objeto seria melhor.
- Reforçar: escolher a estrutura certa evita código extra para "simular" o comportamento que a estrutura já dá de graça.
NOTAS DO PROFESSOR
- Fazer a turma acrescentar um quarto conteúdo e recalcular tipos.
- Erro comum: percorrer o array manualmente para tirar duplicados em vez de usar Set.
- Este exemplo de "conteúdos" volta nos Blocos 10 e 12: fixar bem a estrutura.
NOTAS DO PROFESSOR
- Enfatizar: tipagem dinâmica é uma escolha, não um "defeito" do JavaScript. Traz custos e benefícios.
- Erro comum dos alunos: mudar o tipo de uma variável sem perceber, criando bugs difíceis de encontrar.
- Perguntar: uma linguagem estaticamente tipada (Java) permitiria a segunda linha do exemplo? (não, sem conversão explícita).
NOTAS DO PROFESSOR
- Ligar ao critério de desempenho "tratando e corrigindo erros de forma genérica": esta verificação é exemplo disso.
- Erro comum: nunca verificar o tipo e deixar o programa rebentar mais tarde, longe da causa.
- Exercício rápido: o que acontece se chamarmos mostrarConteudo("texto")? A turma prevê antes de testar.
NOTAS DO PROFESSOR
- A classe ConteudoDigital vai ser a base de todo o exemplo até ao fim da UC. Fixar bem este ponto de partida.
- Erro comum: confundir classe (o molde) com objeto (a instância). Usar a analogia da planta de uma casa vs a casa construída.
- Perguntar: que outras propriedades faria sentido a ConteudoDigital ter? (tipo, url, duração...).
NOTAS DO PROFESSOR
- Este é o coração do critério "conceitos, herança e polimorfismo" do referencial. Não avançar sem isto estar claro.
- Erro comum: esquecer o super(titulo) e o construtor falhar.
- Exercício mental: que outras subclasses de ConteudoDigital fariam sentido? (Video, Quiz, Audio).
NOTAS DO PROFESSOR
- Enfatizar a palavra-chave: "a mesma chamada, comportamentos diferentes".
- Erro comum: achar que polimorfismo exige um nome de método diferente por classe. É o oposto: o nome é igual.
- Analogia: carregar no botão "play" faz coisas diferentes num leitor de música, de vídeo ou de um jogo.
NOTAS DO PROFESSOR
- Este exemplo é a demonstração prática de "criar código genérico para execução de conteúdos digitais".
- Erro comum: escrever um if/else a verificar o tipo de cada item, em vez de deixar o polimorfismo tratar disso.
- Pergunta à turma: se amanhã criarmos a classe Audio, o que muda neste ciclo? (nada, é essa a vantagem).
NOTAS DO PROFESSOR
- Enfatizar: um padrão é vocabulário partilhado, não uma biblioteca a instalar.
- Erro comum: aplicar um padrão "porque sim", complicando um problema simples. Ligar a "evitar complexidades desnecessárias".
- Curiosidade: o livro fundador ("Gang of Four") catalogou 23 padrões em 1994; ainda hoje é referência.
NOTAS DO PROFESSOR
- Não é preciso decorar os 23 padrões clássicos; o importante é reconhecer as três categorias e o raciocínio.
- Erro comum: misturar categorias, achando que Factory resolve comunicação entre objetos.
- Anunciar o próximo bloco: vamos ver Factory, Strategy e Observer aplicados a conteúdos digitais.
NOTAS DO PROFESSOR
- Ligar ao problema real: se amanhã mudar a forma de construir um Video, só se muda num sítio, a factory.
- Erro comum: espalhar "new X()" por todo o código em vez de centralizar na factory.
- Perguntar: o que acontece se pedirmos criarConteudo("audio", ...)? (lança erro, tratamento genérico de erros).
NOTAS DO PROFESSOR
- Mostrar que Strategy já apareceu antes, sem nome: o padrão descreve algo que os alunos já fizeram.
- Erro comum: confundir Observer com uma simples chamada de função. A diferença é a subscrição a um evento.
- Exemplo real: um leitor de vídeo dispara um evento "terminado" e vários módulos reagem (estatísticas, próximo slide).
NOTAS DO PROFESSOR
- Este exemplo recupera e junta tudo o que foi visto: classes, herança, tipagem dinâmica, testes.
- Erro comum: pôr lógica específica de um tipo de conteúdo na classe base. A base deve ficar só com o comum.
- Perguntar: porque é que duracaoSeg tem um valor por omissão (0)? (flexibilidade para conteúdos sem duração, como imagens).
NOTAS DO PROFESSOR
- Fazer a turma identificar o que é específico de Quiz (perguntas) e o que é herdado (titulo).
- Erro comum: repetir a propriedade titulo no construtor da subclasse em vez de usar super().
- Deixar como desafio: criar uma classe Audio seguindo o mesmo padrão.
NOTAS DO PROFESSOR
- A distinção "quem chama quem" é a chave. Dar o exemplo: eu chamo Array.sort(); mas React chama o meu componente.
- Erro comum: usar os dois termos como sinónimos. São relações de controlo diferentes.
- Perguntar: o padrão Observer do Bloco 9 aparece nos frameworks? (sim, é a base dos sistemas de eventos).
NOTAS DO PROFESSOR
- Ligar diretamente ao conhecimento do referencial: "funcionalidades genéricas, arquitetura e extensibilidade".
- Erro comum: alterar o código do núcleo do framework para um caso específico, em vez de usar um ponto de extensão.
- Exemplo real: plugins do WordPress, extensões do VS Code, addons de um motor de jogos.
NOTAS DO PROFESSOR
- Ligar à realização "adaptar código genérico" e à aptidão "ajustar código genérico" do referencial.
- Erro comum clássico: fixar um valor "à mão" no meio da função (hardcoding) em vez de o receber como parâmetro.
- Pergunta: qual das quatro práticas já usámos sem lhe dar nome? (parâmetros, na função ordenar do Bloco 3).
NOTAS DO PROFESSOR
- Este slide fecha o arco iniciado no Bloco 10: prova que a base aguenta um contexto totalmente diferente.
- Erro comum: mexer na classe ConteudoDigital para "encaixar" o novo caso, em vez de estender.
- Deixar como reflexão: que outro contexto (loja online, rede social) usaria a mesma base?
NOTAS DO PROFESSOR
- Ligar à realização "testes de funcionalidades" e ao valor de testar o método genérico testar() herdado.
- Erro comum: só testar o "caminho feliz" e esquecer valores vazios ou inesperados.
- Se houver tempo, mostrar uma ferramenta real de testes (ex.: Jest) como evolução do console.assert.
NOTAS DO PROFESSOR
- Este é o exemplo direto do critério "tratando e corrigindo erros de forma genérica".
- Erro comum: envolver tudo em try/catch sem nunca ler o erro (catch vazio). Mostrar porque é mau hábito.
- Perguntar: que conteúdos, de entre os que a turma criou, podiam provocar erro ao renderizar?
NOTAS DO PROFESSOR
- Este bloco cobre um conhecimento explícito do referencial que é fácil de esquecer numa UC "só de código".
- Erro comum: achar que segurança no trabalho só se aplica a oficinas ou fábricas.
- Pergunta à turma: quantas horas seguidas passam sentados a programar sem pausa?
NOTAS DO PROFESSOR
- Ligar ao conhecimento "normas de proteção ambiental" e à atitude "responsabilidade pelas suas ações".
- Erro comum: achar que ambiente e programação são temas sem relação. A pegada digital é real e crescente.
- Exemplo: comparar o tamanho de uma imagem não otimizada com uma otimizada e o impacto no carregamento.
NOTAS DO PROFESSOR
- Usar este checklist como grelha de autoavaliação antes das fichas e do projeto.
- Erro comum: dar o código por terminado assim que "funciona uma vez", sem passar pela checklist.
- Anunciar as fichas e o projeto: aplicar tudo isto a uma biblioteca de conteúdos interativos de raiz.