Questões de Padrões de projeto (Design Patterns) (Arquitetura de Software)

Limpar Busca

A respeito de padrões de criação, julgue o item subsecutivo.


Conforme o padrão Singleton, um sistema que necessite de um único objeto de uma classe, após o programa instanciar o objeto, não deve ter permissão de criar objetos adicionais dessa classe.

  • Certo
  • Errado

Acerca de padrões estruturais, julgue o item subsequente.


O propósito do padrão Adapter é separar uma abstração de sua implementação, para que as duas possam variar e ser independentes.

  • Certo
  • Errado

Acerca de padrões estruturais, julgue o item subsequente.


Um cliente que precisa tratar, de maneira uniforme, objetos individuais e suas composições deve utilizar, para essa finalidade, o padrão Facade.

  • Certo
  • Errado

Com relação a padrões comportamentais, julgue o item seguinte.


O padrão Iterator oferece uma forma flexível de uso de herança para estender uma funcionalidade.

  • Certo
  • Errado

Ao construir uma aplicação bancária, um projetista de software modelou a classe “Conta”. Posteriormente, percebeu que cada instância da classe “Conta” poderia ter um conjunto de responsabilidades variadas e independentes, sendo que uma requisição poderia ter que ser atendida por uma ou várias dessas responsabilidades. Isso não permitiria usar de forma eficiente o mecanismo de subclasses para representar essas responsabilidades. Buscando uma solução adequada para essa limitação, o projetista encontrou um padrão de projeto que permite adicionar e retirar dinamicamente responsabilidades apenas aos objetos individuais, e não à classe inteira, estendendo a funcionalidade do objeto, o que seria a solução ideal para o seu caso.
Esse padrão de projeto específico tem uma estrutura comum, em que existe uma

  • A superclasse abstrata, por exemplo “ComponenteConta”, que também é superclasse de uma segunda classe, e essa segunda classe, também abstrata, será superclasse das várias classes concretas que representam as responsabilidades adicionais.
  • B classe, por exemplo “InterfaceConta”, que converte a interface de uma classe em outra interface que o cliente espera, evitando incompatibilidades causadas por interfaces diferentes.
  • C classe, por exemplo “FabricaContas”, que separa a construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
  • D classe que define uma dependência um-para-muitos entre objetos, de forma que, quando o estado de um objeto da classe “Conta” é alterado, todos os outros objetos dependentes são notificados e podem implementar atualização automática de suas propriedades, em uma relação publicar-subscrever.
  • E classe abstrata, por exemplo “InterfaceConta”, cuja finalidade é definir a interface que permite que suas subclasses tratem uma requisição, sendo que as subclasses concretas são estruturadas em uma cadeia onde cada classe trata a requisição ou a envia para a classe sucessora, até que uma delas atenda a requisição.