UC04371

Desenvolver código genérico para conteúdos digitais

Programação genérica, algoritmos, estruturas de dados, orientação a objetos, design patterns e frameworks

Curso profissional · 25h · Técnico de Produção de Conteúdos Interativos

Plano

  1. Programação genérica: conceitos e princípios
  2. Tipos de linguagens de programação
  3. Algoritmos genéricos e tipos de dados
  4. Estruturas de dados genéricas
  5. Tipagem dinâmica
  6. Orientação a objetos: classes e herança
  7. Polimorfismo
  8. Design patterns: conceitos e princípios
  9. Padrões mais usados em conteúdos digitais
  10. Código genérico aplicado: herança e polimorfismo
  11. Frameworks e bibliotecas flexíveis
  12. Adaptar código genérico a diferentes contextos
  13. Testes de funcionalidades
  14. Segurança, saúde no trabalho e ambiente
  15. Boas práticas e fecho

Bloco 1 · Programação genérica

O que é código genérico

Código genérico é código escrito para funcionar com vários tipos de dados ou de conteúdos, sem ter de ser reescrito para cada caso específico. Em vez de uma função só para imagens, uma só para vídeos e outra só para questionários, escreve-se uma função que serve para os três.

  • Objetivo: reutilização e menos duplicação.
  • Aplica-se a conteúdos digitais: uma galeria, um leitor de vídeo, um quiz interativo podem partilhar a mesma lógica de base.
  • É um dos critérios de desempenho da UC: assegurar uma adaptação eficiente do código ao contexto e ao projeto.

Princípios da programação genérica

  • DRY (Don't Repeat Yourself): não escrever a mesma lógica duas vezes.
  • Abstração: pensar no que os conteúdos têm em comum antes de pensar nas diferenças.
  • Independência de tipo: a função não deve exigir saber, à partida, se recebe uma imagem ou um vídeo.
  • Baixo acoplamento: módulos que dependem pouco uns dos outros são mais fáceis de adaptar.
  • Evitar complexidades desnecessárias: genérico não é sinónimo de complicado.

Bloco 2 · Tipos de linguagens de programação

Classificar linguagens por paradigma

Um paradigma é uma forma de organizar o raciocínio ao escrever código:

Paradigma Ideia central Exemplo de linguagem
Imperativo sequência de instruções que mudam o estado C, JavaScript
Orientado a objetos dados e comportamento agrupados em objetos Java, C#, JavaScript
Funcional funções puras, sem efeitos secundários Haskell, partes de JS
Declarativo descreve o resultado, não os passos SQL, HTML/CSS

A maioria das linguagens modernas (JavaScript, Python) combina paradigmas.

Compiladas vs interpretadas, estáticas vs dinâmicas

  • Compiladas: o código é traduzido para linguagem de máquina antes de correr (C, Java parcialmente).
  • Interpretadas: o código é lido e executado linha a linha em tempo de execução (JavaScript, Python).
  • Tipagem estática: o tipo de cada variável é fixado e verificado antes de correr (Java, TypeScript).
  • Tipagem dinâmica: o tipo é determinado em tempo de execução e pode mudar (JavaScript, Python).

Para conteúdos digitais na web, a combinação mais comum é interpretada + tipagem dinâmica: o JavaScript.

Bloco 3 · Algoritmos genéricos e tipos de dados

O que é um algoritmo genérico

Um algoritmo genérico resolve um problema de forma independente do tipo concreto de dado que recebe. Por exemplo, um algoritmo de ordenação que funciona tanto para números como para nomes de ficheiros.

function ordenar(lista, comparar) {
  return [...lista].sort(comparar);
}

ordenar([5, 2, 9], (a, b) => a - b);
ordenar(["zebra", "abelha"], (a, b) => a.localeCompare(b));

A função ordenar não sabe, à partida, se vai receber números ou texto: recebe também a regra de comparação.

Tipos de dados primitivos e compostos

  • Primitivos: número, texto (string), booleano, null/undefined.
  • Compostos: array (lista ordenada), objeto (pares chave-valor), e estruturas mais avançadas (conjuntos, mapas).
  • Um algoritmo genérico costuma operar sobre dados compostos (uma coleção de conteúdos), aplicando a mesma lógica a cada elemento.
  • Saber identificar o tipo de dado certo para o problema é o primeiro passo para escrever um algoritmo genérico correto.

Bloco 4 · Estruturas de dados genéricas

As estruturas de dados essenciais

Estrutura O que guarda Uso típico em conteúdos digitais
Array / lista elementos ordenados lista de slides, galeria de imagens
Objeto / dicionário pares chave-valor as propriedades de um conteúdo (título, tipo, url)
Conjunto (Set) valores únicos tags sem repetição
Fila (Queue) primeiro a entrar, primeiro a sair fila de reprodução de vídeos
Pilha (Stack) último a entrar, primeiro a sair histórico de "recuar" num quiz

Cada estrutura é genérica: guarda qualquer tipo de conteúdo, desde que se respeite a mesma forma.

Escolher a estrutura certa

Exemplo: gerir uma coleção de conteúdos digitais de um curso.

const conteudos = [
  { id: 1, tipo: "imagem", titulo: "Capa" },
  { id: 2, tipo: "video",  titulo: "Introdução" },
  { id: 3, tipo: "quiz",   titulo: "Autoavaliação" },
];

const tipos = new Set(conteudos.map(c => c.tipo));
  • O array guarda a coleção ordenada.
  • Cada objeto guarda as propriedades de um conteúdo, genéricas para qualquer tipo.
  • O Set dá, sem esforço extra, a lista de tipos sem repetições.

Bloco 5 · Tipagem dinâmica

O que é tipagem dinâmica

Em tipagem dinâmica, o tipo de uma variável não é declarado à partida: é determinado em tempo de execução, pelo valor que ela guarda em cada momento.

let valor = 10;        // número
valor = "dez";         // agora é texto
valor = [1, 2, 3];      // agora é array
  • Vantagem: flexibilidade, código mais curto, ideal para código genérico que aceita vários tipos.
  • Risco: erros que só aparecem em execução (ex.: somar um número com um texto por engano).

Trabalhar com tipagem dinâmica em segurança

  • Verificar o tipo com typeof antes de operar sobre um valor incerto.
  • Usar valores por omissão para evitar undefined inesperado.
  • Documentar, em comentário, que tipo cada função espera receber.
function mostrarConteudo(item) {
  if (typeof item !== "object" || item === null) {
    throw new Error("mostrarConteudo espera um objeto de conteúdo");
  }
  console.log(`${item.tipo}: ${item.titulo}`);
}

A tipagem dinâmica dá liberdade, mas o código genérico bem escrito verifica em vez de assumir.

Bloco 6 · Orientação a objetos: classes e herança

Classes e objetos

Uma classe é um molde que descreve as propriedades e o comportamento comuns a um conjunto de objetos.

class ConteudoDigital {
  constructor(titulo) {
    this.titulo = titulo;
  }
  descrever() {
    return `Conteúdo: ${this.titulo}`;
  }
}

const c1 = new ConteudoDigital("Capa do curso");
  • Encapsulamento: os dados (titulo) e o comportamento (descrever) vivem juntos.
  • Cada new ConteudoDigital(...) cria um objeto, uma instância concreta da classe.

Herança: reaproveitar código genérico

A herança permite criar uma classe nova a partir de outra, reaproveitando o que já existe e acrescentando só o que muda.

class Imagem extends ConteudoDigital {
  constructor(titulo, url) {
    super(titulo);
    this.url = url;
  }
}

const cartaz = new Imagem("Cartaz", "cartaz.jpg");
cartaz.descrever(); // herdado de ConteudoDigital
  • extends liga Imagem a ConteudoDigital.
  • super(titulo) chama o construtor da classe-mãe.
  • Imagem herda descrever() sem o reescrever.

Bloco 7 · Polimorfismo

O que é polimorfismo

Polimorfismo é a capacidade de objetos de classes diferentes responderem à mesma chamada de forma diferente, cada um ao seu modo.

class ConteudoDigital {
  render() { return "conteúdo genérico"; }
}
class Video extends ConteudoDigital {
  render() { return "a reproduzir vídeo"; }
}
class Quiz extends ConteudoDigital {
  render() { return "a mostrar pergunta"; }
}

Cada subclasse sobrepõe (override) o método render() com o seu comportamento próprio.

Polimorfismo em ação: percorrer sem saber o tipo

const conteudos = [new Video(), new Quiz(), new ConteudoDigital()];

for (const item of conteudos) {
  console.log(item.render());
}
// a reproduzir vídeo
// a mostrar pergunta
// conteúdo genérico
  • O ciclo não sabe se cada item é vídeo, quiz ou genérico: chama sempre render().
  • É isto que torna o código genérico: uma função serve para qualquer subclasse futura, sem alterações.

Bloco 8 · Design patterns: conceitos e princípios

O que são design patterns

Um design pattern (padrão de projeto) é uma solução testada para um problema que se repete no desenho de software, com um nome e um vocabulário partilhados pelos programadores.

  • Não é código pronto a copiar: é uma estrutura de raciocínio a adaptar a cada caso.
  • Facilita a comunicação entre a equipa ("usa um Factory aqui").
  • Ajuda a escrever código genérico, testado por milhares de projetos antes do nosso.

Categorias de design patterns

Categoria Resolve Exemplos
Criação como instanciar objetos Factory, Singleton
Estrutura como organizar classes e objetos Adapter, Decorator
Comportamento como objetos comunicam entre si Strategy, Observer

Nesta UC vemos, em detalhe, um padrão de cada categoria relevante para conteúdos digitais.

Bloco 9 · Padrões mais usados em conteúdos digitais

O padrão Factory

O Factory centraliza a criação de objetos numa única função, que decide qual classe instanciar com base num parâmetro.

function criarConteudo(tipo, titulo) {
  switch (tipo) {
    case "imagem": return new Imagem(titulo);
    case "video":  return new Video(titulo);
    case "quiz":   return new Quiz(titulo);
    default: throw new Error(`Tipo desconhecido: ${tipo}`);
  }
}

const item = criarConteudo("video", "Aula 1");

O resto do programa nunca escreve new Video(...) diretamente: só pede à factory.

Os padrões Strategy e Observer

Strategy: encapsula um algoritmo intercambiável, passado como parâmetro (já usámos isto na função ordenar do Bloco 3).

const estrategiaOrdenar = (a, b) => a.titulo.localeCompare(b.titulo);
conteudos.sort(estrategiaOrdenar);

Observer: um objeto (o sujeito) notifica vários observadores quando algo muda, sem os conhecer em detalhe.

document.addEventListener("conteudoTerminado", () => {
  console.log("Avançar para o próximo conteúdo");
});

Bloco 10 · Código genérico aplicado

Exemplo passo a passo: a classe base

Construir uma pequena biblioteca genérica para conteúdos interativos, começando pela base:

class ConteudoDigital {
  constructor(titulo, duracaoSeg = 0) {
    this.titulo = titulo;
    this.duracaoSeg = duracaoSeg;
  }
  render() {
    return `Conteúdo genérico: ${this.titulo}`;
  }
  testar() {
    return typeof this.titulo === "string" && this.titulo.length > 0;
  }
}

O método testar() é genérico: qualquer subclasse o herda sem alterações.

Exemplo passo a passo: as subclasses

class Video extends ConteudoDigital {
  render() {
    return `A reproduzir "${this.titulo}" (${this.duracaoSeg}s)`;
  }
}

class Quiz extends ConteudoDigital {
  constructor(titulo, perguntas) {
    super(titulo);
    this.perguntas = perguntas;
  }
  render() {
    return `Quiz "${this.titulo}" com ${this.perguntas.length} pergunta(s)`;
  }
}

Cada subclasse acrescenta só o que é específico; o resto vem da classe base, por herança.

Bloco 11 · Frameworks e bibliotecas flexíveis

Framework vs biblioteca

  • Biblioteca: um conjunto de funções que o nosso código chama quando precisa (nós controlamos o fluxo).
  • Framework: uma estrutura que chama o nosso código em pontos definidos (o framework controla o fluxo, o chamado "princípio de inversão de controlo").
Biblioteca Framework
Quem controla o fluxo o programador o framework
Exemplo uma função de datas React, Vue
Flexibilidade maior segue convenções

Funcionalidades genéricas, arquitetura e extensibilidade

Um framework ou biblioteca flexível para conteúdos digitais costuma oferecer:

  • Funcionalidades genéricas: carregar, mostrar e remover qualquer tipo de conteúdo.
  • Arquitetura em camadas: separar dados, lógica e apresentação.
  • Extensibilidade: pontos de extensão (plugins, hooks) para acrescentar tipos de conteúdo novos sem alterar o núcleo.
registarTipoDeConteudo("audio", Audio); // extensão sem tocar no núcleo

Um bom framework cresce com o projeto, sem obrigar a reescrever o que já funciona.

Bloco 12 · Adaptar código genérico a diferentes contextos

Práticas de adaptação do código

Adaptar código genérico é configurá-lo, não reescrevê-lo:

  • Parâmetros e opções: passar valores para alterar o comportamento ({ autoplay: true }).
  • Injeção de dependências: passar a função ou o objeto certo em vez de o fixar dentro do código.
  • Configuração externa: um ficheiro de definições em vez de valores fixos no código (hardcoded).
  • Composição: combinar peças pequenas e genéricas em vez de uma peça grande e específica.

Um código bem adaptável muda de comportamento sem ser alterado por dentro.

Exemplo: adaptar a biblioteca a um novo contexto

A mesma classe ConteudoDigital do Bloco 10, adaptada para um novo contexto (um museu virtual, em vez de um curso):

class Exponente extends ConteudoDigital {
  constructor(titulo, sala) {
    super(titulo);
    this.sala = sala;
  }
  render() {
    return `Exponente "${this.titulo}" na sala ${this.sala}`;
  }
}

Nada mudou na classe base nem no ciclo do Bloco 7: só se acrescentou uma subclasse nova. Isto é código genérico bem-sucedido.

Bloco 13 · Testes de funcionalidades

Porque e como testar

Testar é verificar, de forma sistemática, que o código faz o que devia fazer, incluindo em casos-limite.

  • Teste manual: correr o programa e observar o resultado.
  • Teste automatizado: escrever código que verifica o código (mais fiável e repetível).
  • Casos-limite: valores vazios, null, tipos inesperados (importante com tipagem dinâmica).
console.assert(new Video("Aula").testar() === true, "Video válido devia passar");
console.assert(new Video("").testar() === false, "Título vazio devia falhar");

Tratar erros de forma genérica

Uma função genérica deve prever que pode receber dados inesperados e reagir de forma consistente, não com um comportamento diferente por caso.

function renderSeguro(item) {
  try {
    return item.render();
  } catch (erro) {
    console.error(`Falha ao renderizar: ${erro.message}`);
    return "Conteúdo indisponível";
  }
}

try/catch isola o erro sem parar o resto do programa, um dos critérios de desempenho da UC.

Bloco 14 · Segurança, saúde no trabalho e ambiente

Normas de segurança e saúde no trabalho

Programar é trabalho sentado, repetitivo e de ecrã: também tem normas de saúde no trabalho.

  • Postura: ecrã à altura dos olhos, costas direitas, pés apoiados.
  • Pausas regulares: a cada 50 a 60 minutos, levantar e descansar a vista (regra dos 20-20-20: a cada 20 min, olhar 20 segundos para algo a 20 pés/6 metros).
  • Iluminação e ergonomia do posto de trabalho: evitar reflexos no ecrã, cadeira e mesa ajustadas.
  • Organização do cabo e do posto, para evitar quedas e riscos elétricos.

Normas de proteção ambiental

Também o desenvolvimento de código tem impacto ambiental, direto e indireto:

  • Eficiência do código: código mais eficiente consome menos energia no servidor e no dispositivo do utilizador.
  • Otimizar recursos: imagens e vídeos bem dimensionados reduzem tráfego e consumo energético.
  • Equipamento: prolongar a vida útil do equipamento informático; reciclar corretamente o que é descartado.
  • Consumo consciente: desligar equipamento não utilizado, preferir modos de poupança de energia.

Rigor no código também é uma forma de responsabilidade ambiental.

Bloco 15 · Boas práticas e fecho

Checklist de código genérico de qualidade

Antes de dar um módulo genérico por terminado, verificar:

  • [ ] Cobre os requisitos específicos identificados no início (análise).
  • [ ] Usa herança e polimorfismo onde reduz duplicação, sem forçar a árvore de classes.
  • [ ] Escolheu a estrutura de dados certa para o problema.
  • [ ] Trata erros de forma consistente, sem parar o programa todo.
  • [ ] Foi testado, incluindo casos-limite.
  • [ ] É fácil de adaptar a um contexto novo, sem alterar o núcleo.
  • [ ] Não tem complexidade desnecessária.

Recapitulando

  • Código genérico reutiliza lógica entre tipos diferentes de conteúdos digitais, com DRY e abstração.
  • Algoritmos e estruturas de dados genéricas (arrays, objetos, sets) são a base de qualquer módulo reutilizável.
  • Tipagem dinâmica, herança e polimorfismo permitem que uma mesma base sirva vídeo, quiz, imagem e mais.
  • Design patterns (Factory, Strategy, Observer) dão vocabulário e soluções testadas a problemas recorrentes.
  • Frameworks flexíveis, adaptação e testes fecham o ciclo: código genérico, testado e pronto a crescer.

Próximo: fichas e projeto, construir uma biblioteca genérica de conteúdos interativos.

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.