✅ Alternativa correta: C

  Factory Method

Explicação:

Cenário descrito:

  O sistema gerencia diversos tipos de documentos (petições, sentenças, relatórios).

  Cada tipo pode ter regras e comportamentos diferentes.

  O sistema deve ser modular, ou seja:

    Permitir adição de novos tipos de documentos sem impactar o código existente.

    Evitar modificações diretas nos componentes centrais.

Solução ideal: Padrão Factory Method

O que é o Factory Method?

  Um padrão criacional que define uma interface para criar objetos, mas permite às subclasses decidir qual classe instanciar.

  É perfeito para cenários com muitas variações de um tipo base, como:

    Documentos que herdam de uma interface Documento, mas se comportam de forma diferente (ex: Peticao, Sentenca, RelatorioAudiencia).

❌ Por que as outras alternativas estão erradas?

Alternativa Por que não se aplica

A – Singleton Garante uma única instância global. Não resolve modularidade nem criação flexível de objetos.

B – Adapter Serve para adaptar interfaces incompatíveis. Não é sobre criação ou modularidade.

D – Composite Serve para representar estruturas em árvore, como menus ou arquivos e pastas.

E – Decorator Serve para adicionar funcionalidades a um objeto em tempo de execução, mas não resolve criação modular com diferentes classes.

Fonte: ChatGPT.

O padrão de projeto mais adequado para esse cenário é o Factory Method (Alternativa C).

Justificativa:

O problema central é a criação flexível de diferentes tipos de documentos (petições, sentenças, relatórios) com requisitos variados, garantindo:

1. Extensibilidade modular: Adicionar novos tipos de documentos sem alterar o código existente.
2. Baixo acoplamento: Isolar as regras de criação de cada documento, evitando impacto no sistema geral.

Como o Factory Method resolve:

• Define uma interface única para criar documentos (ex: ).
• Cada tipo de documento (petição, sentença, etc.) implementa sua própria lógica de criação em subclasses especializadas.
• Novos documentos são adicionados criando novas subclasses sem modificar o código cliente existente.

Por que as outras alternativas não se aplicam:

• Singleton (A): Controla instância única (ex: conexão com BD), irrelevante para criação de múltiplos documentos.
• Adapter (B): Converte interfaces incompatíveis, não trata criação modular.
• Composite (D): Gerencia hierarquias de objetos (ex: pastas com documentos), não foca na criação.
• Decorator (E): Adiciona comportamentos dinâmicos (ex: criptografia), mas não resolve a variação na criação de objetos.

Conclusão:

O Factory Method é ideal para encapsular a criação de objetos com variações (como os tipos de documentos judiciais), garantindo modularidade e conformidade com o Open/Closed Principle.

Resposta: Alternativa C (Factory Method).

Requisito central: facilidade de expansão modular → adicionar novos tipos de documentos sem afetar o restante do sistema.

Avaliando as alternativas:

• A) Singleton errado. Serve apenas para garantir uma única instância de uma classe. Não resolve modularidade ou criação de vários tipos de documentos.
• B) Adapter errado. Usado para adaptar interfaces incompatíveis. Não é o caso aqui.
• C) Factory Method certo. É o padrão criacional que define uma interface para criar objetos, mas deixa para as subclasses a decisão de qual classe instanciar. Perfeito para o caso: novos tipos de documentos (Petições, Sentenças, Relatórios) podem ser adicionados sem alterar o código cliente, apenas criando novas fábricas/métodos de criação.
• D) Composite errado. Usado para tratar objetos individuais e composições de forma uniforme (árvores hierárquicas). Não se aplica diretamente aqui.
• E) Decorator (escrito “Decorat”) errado. Serve para adicionar responsabilidades dinamicamente a objetos, não para modularizar criação de tipos diferentes.

• Singleton → controla instância única. Não resolve modularidade nem criação flexível.
• Adapter → adapta interfaces incompatíveis. Não é o caso.
• Composite → trata estruturas em árvore (parte-todo). Não é o problema descrito.
• Decorator → adiciona comportamento dinamicamente, mas não resolve a criação desacoplada de diferentes tipos de documento.
• Factory Method → permite criar objetos sem acoplar o código à classe concreta. Novos tipos de documento podem ser adicionados criando novas subclasses, sem alterar o código cliente.

Aqui o ponto-chave é:

“novos tipos de documento sem afetar o sistema como um todo”.

Isso é exatamente o propósito do Factory Method: delegar a criação para subclasses e evitar dependência direta de classes concretas.

Resposta correta:

C) Factory Method.