Mini-Projecto · Biblioteca genérica de conteúdos interativos

Contexto

A "Escola Digital", um centro de formação, quer um pequeno módulo de código que sirva de base a vários produtos: uma plataforma de e-learning, um museu virtual e um catálogo de uma loja. Em vez de construir três soluções separadas, pediram-te uma biblioteca genérica de conteúdos interativos: uma base comum, escrita uma vez, que qualquer um dos três produtos pode estender sem alterar o núcleo.

Trabalhas individualmente ou a pares, em JavaScript, e entregas o código a funcionar mais um pequeno dossiê (requisitos analisados, decisões de design e testes realizados).

Requisitos

Funcionais

• Classe base ConteudoDigital, com titulo e um método genérico render().
• No mínimo três subclasses por herança (por exemplo Imagem, Video, Quiz), cada uma com render() próprio (polimorfismo).
• Uma estrutura de dados genérica (array de objetos) para gerir uma coleção de conteúdos de tipos diferentes.
• Uma função Factory (criarConteudo(tipo, ...)) que centraliza a criação das instâncias.
• Um ciclo genérico que percorre a coleção e chama render() em cada item, sem verificar o tipo com if/else.
• Uma função de tratamento de erros genérico (renderSeguro) que isola falhas de um item sem parar o programa.
• Testes (console.assert ou equivalente) que cubram, no mínimo, um caso válido e um caso-limite por funcionalidade.

Não-funcionais

• Código sem duplicação evidente entre subclasses (o que é comum vive na classe base).
• Sem valores fixos (hardcoding) onde deveria haver um parâmetro configurável.
• Comentários que expliquem decisões, não o óbvio.
• Nenhuma alteração à classe base para acrescentar um tipo de conteúdo novo (extensão, não modificação).

Fases

Critérios de avaliação

Erros comuns

• Repetir titulo no construtor de cada subclasse em vez de usar super(titulo).
• Verificar o tipo do item com if (item instanceof Video) antes de chamar render(), em vez de confiar no polimorfismo.
• Espalhar new Video(...) pelo código, sem passar pela Factory.
• Alterar a classe ConteudoDigital na Fase 5, em vez de só estender.
• Testar apenas o caso "tudo certo" e esquecer o título vazio ou null.
• Deixar um catch vazio em renderSeguro, sem registar o erro.

Bónus (opcional)

• Implementar um padrão Observer: disparar um evento quando um conteúdo é renderizado, e um segundo módulo reagir (por exemplo, contando quantos conteúdos já foram mostrados).
• Acrescentar uma opção de configuração (ex.: { idioma: "pt" }) injetada na Factory, sem alterar as subclasses.
• Medir e comentar o impacto de otimizar os dados (ex.: não carregar imagens de conteúdos ainda não visíveis) na eficiência e no consumo energético.

Reflexão

No dossiê final, responde: qual foi a decisão de design mais importante para que a Fase 5 (extensão) não exigisse tocar na classe base? E dá um exemplo, fora deste projeto, de um sistema real (aplicação, jogo, site) que provavelmente usa uma classe base genérica com várias subclasses.