Ao invés de colocarmos o cálculo do frete de um pedido na classe Pedido, optamos por criar uma hierarquia para encapsular os diferentes algoritmos de cálculo de frete que temos no sistema. Assinale a alternativa com o nome do padrão GRASP que recomenda a criação de classes que não representam diretamente elementos concretos encontrados no domínio no negócio, seguindo uma decomposição de responsabilidades por comportamento e não por representação, como a descrita no cálculo de frete.

Alternativa A - Invenção Pura

Padrão GRASP: Invenção Pura

O cenário descrito na questão exemplifica perfeitamente o princípio da Invenção Pura. Este princípio recomenda a criação de novas classes que não correspondem a nada existente no mundo real ou no domínio do negócio, mas servem para organizar melhor o código.

Análise Detalhada:

• O Problema: Colocar o cálculo do frete diretamente na classe Pedido mistura dados (o pedido) com lógica de negócio específica (cálculo de frete). Isso viola princípios de baixo acoplamento e alta coesão.
• A Solução: Criar uma hierarquia de classes dedicada apenas ao cálculo de frete. Essas classes são "invenções puras" porque não representam um objeto físico ou conceitual direto do negócio (como Cliente, Produto ou Pedido), mas sim um comportamento complexo agrupado.
• Objetivo: Simplificar o sistema, facilitando a manutenção e a evolução futura, já que novos tipos de frete podem ser adicionados sem alterar a classe principal Pedido.

Comparação com outras alternativas:

Em resumo, ao inventar classes para encapsular algoritmos que não pertencem naturalmente aos objetos do domínio, aplica-se a Invenção Pura.