Questão de Arquitetura de Software — Padrões de projeto (Design Patterns) — CESGRANRIO 2006
Arquitetura de SoftwarePadrões de projeto (Design Patterns)
- Código
- cg025638
- Banca
- CESGRANRIO
- Órgão
- Petrobras
- Ano
- 2006
- Nível
- Superior
- Cargo
- Petrobrás - Analista de Sistemas Pleno - Engenharia de Software
Christopher Alexander afirma: "cada padrão descreve um problema no nosso ambiente e o cerne da sua solução, de tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca faze-lo da mesma maneira". Muito embora Alexander estivesse falando a cerca de padrões em construções e cidades, o que ele diz é verdadeiro em relação aos padrões de projeto orientados a objeto. Neste caso, as soluções são expressas em termos de objetos e interfaces em vez de paredes e portas, mas no cerne de ambos os tipos de padrões está a solução para um problema num determinado contexto. Quanto à indicação para o uso dos padrões de projeto é FALSO afirmar que o padrão:
- AAbstract Factory é indicado quando: um sistema deve ser independente de como seus produtos são criados, compostos ou representados; um sistema deve ser configurado como um produto de uma família de múltiplos produtos; uma família de objetos-produto for projetada para ser usada em conjunto, e você necessita garantir esta restrição; você quer fornecer uma biblioteca de classes de produtos e quer revelar somente suas interfaces, não suas implementações.
- BBuilder é indicado quando: uma classe não pode antecipar a classe de objetos que deve criar; uma classe quer que suas subclasses especifiquem os objetos que criam; classes delegam responsabilidade para uma dentre várias subclasses auxiliares, e você quer localizar o conhecimento de qual subclasse auxiliar que é a delegada.
- CMediator é indicado quando: um conjunto de objetos se comunica de maneiras bem definidas, porém complexas; a reutilização de um objeto é difícil porque ele referencia e se comunica com muitos outros objetos; um comportamento que está distribuído entre várias classes deveria ser customizável, ou adaptável, sem excessiva especialização em subclasses.
- DMemento é indicado quanto: um instantâneo de estado de um objeto deve ser salvo de maneira que possa ser restaurado para esse estado mais tarde; uma interface direta para obtenção do estado exporia detalhes de implementação e romperia o encapsulamento do objeto.
- EComposite é indicado quando: quiser representar hierarquias partes-todo de objetos; quiser que os clientes sejam capazes de ignorar a diferença entre composições de objetos e objetos individuais, neste caso, os clientes tratarão todos os objetos na estrutura composta de maneira uniforme