PADRÕES DE PROJETO DE SOFTWARE

Prévia do material em texto

1a Questão (Ref.: 201603684263)
	Acerto: 1,0  / 1,0
	considere a afirmativa de Gamma e Al. citada abaixo e escolha a opção correta: ¿ Em geral, todas as arquiteturas orientadas a objeto bem-estruturadas estão cheias de padrões. Uma das maneiras de medir a qualidade de um sistema orientado a objetos é avaliar se os colaboradores tomaram bastante cuidado com as colaborações comuns entre seus objetos. Focalizar em tais mecanismos durante o desenvolvimento de um sistema pode levar a uma arquitetura menor, mais simples, muito mais compreensível do que aquelas produzidas quanto padrões são ignorados.¿
		
	 
	Padrões são boas práticas e proporcionam garantia de qualidade na elaboração do código.
	
	Padrões é uma forma obrigatória de programar com objetos
	
	Padrões sempre levam a uma arquitetura menor principalmente quando se usa tecnologia de objetos
	
	Padrões causam falta de criatividade nos desenvolvedores e esta perda compromete a qualidade.
	
	Padrões são de uso obrigatório e eliminam os erros cometidos na fase programação.
		
	
	
	 2a Questão (Ref.: 201604240801)
	Acerto: 1,0  / 1,0
	Um design pattern descreve uma solução geral comprovada e reutilizável para um problema recorrente no desenvolvimento de sistemas de software orientados a objetos. Padrões de projeto ajudam a reconhecer e implementar boas soluções para problemas comuns. Dois dos principais design patterns utilizados atualmente são descritos a seguir: I. Visa garantir que uma classe só tenha uma única instância e prover um ponto de acesso global a ela. II. Visa definir uma dependência um-para-muitos entre objetos para que quando um objeto mudar de estado os seus dependentes sejam notificados e atualizados automaticamente. Os design patterns descritos em I e II são, respectivamente:
		
	
	Facade e Observer.
	 
	Singleton e Observer.
	
	Singleton e Command.
	
	Facade e Adapter.
	
	Composite e Adapter
		
	
	
	 3a Questão (Ref.: 201604304617)
	Acerto: 1,0  / 1,0
	Assinale dentre as opções abaixo, qual o padrão de projeto mais conhecidos e extensivamente utilizados em programação orientada a objetos e que está direcionado para as situações onde é preciso manter uma única instancia de uma classe durante toda a execução da aplicação.
		
	
	Composite;
	
	Prototipe:
	 
	Singleton
	
	Decorator;
	
	Builder;
		 Gabarito Comentado.
	
	
	 4a Questão (Ref.: 201603683847)
	Acerto: 1,0  / 1,0
	Segundo Metsker, o padrão de projeto GoF _________________ é aplicado para substituir a geração de instâncias não-inicializadas de uma classe, fornecendo novos objetos a partir de uma classe-exemplo.
		
	
	FACTORY METHOD.
	
	BUILDER.
	
	SINGLETON.
	 
	PROTOTYPE.
	
	MEDIATOR.
		
	
	
	 5a Questão (Ref.: 201604268931)
	Acerto: 1,0  / 1,0
	Construtores em Java definem uma maneira padrão de construir objetos. No entanto, depender de construtores para instanciar objetos pode nos levar a alguns problemas dos quais podemos citar, exceto:
		
	
	A aplicação cliente fica acoplada diretamente a uma implementação concreta para poder usar diretamente o construtor
	 
	Não é preciso saber a classe concreta do objeto para criá-lo
	
	Usando diretamente os métodos construtores não há como limitar o número de instâncias criadas
	
	Objeto complexo pode necessitar da criação de objetos menores previamente, com certo controle difícil de implementar com construtores
	
	Cliente pode não ter ou não saber todos os dados necessários para instanciar um objeto através de construtores
		
	
	
	 6a Questão (Ref.: 201604251881)
	Acerto: 1,0  / 1,0
	Observe a figura abaixo e escolha dentre as opções o padrão GOF para resolver o problema com a estrutura apresentada.
		
	
	GRASP
	
	Chain of Responsability
	
	Observer
	
	JEE
	 
	Composite
		
	
	
	 7a Questão (Ref.: 201603694858)
	Acerto: 1,0  / 1,0
	(CESGRANRIO - 2009) O presidente de uma empresa determinou que fosse disponibilizado um sistema de vendas na Internet. No entanto, o software de controle de estoque que deve ser acessado pela aplicação de vendas é muito antigo e provê uma API (Application Programming Interface) de uso muito complicado. Para que os desenvolvedores possam acessar uma interface mais simples, o arquiteto do sistema pode determinar o uso do padrão de projeto
		
	
	Decorator.
	
	Flyweight.
	
	Prototype.
	
	Observer.
	 
	Façade.
		
	
	
	 8a Questão (Ref.: 201604284003)
	Acerto: 1,0  / 1,0
	A classe Façade, em qualquer contexto, tem como objetivo mais amplo buscar respostas para um problema de forma transparente em um conjunto de subsistemas e fornecer uma resposta imediata para a classe cliente. Assinale dentre as principais vantagens desse padrão de projeto a única que não é verdadeira.:
		
	
	Incentivar acoplamento fraco entre o subsistema e seus clientes.
	
	Tornar os clientes independentes da complexidade dos diferentes subsistemas de uma aplicação.
	
	judar a melhorar portabilidade dos sistemas.
	 
	Incentivar acoplamento forte entre o subsistema e seus clientes.
	
	Simplificar o acesso a determinadas funcionalidades de um subsistema, sem inviabilizar sua utilização direta.
		
	
	
	 9a Questão (Ref.: 201604360907)
	Acerto: 1,0  / 1,0
	São exemplos de Padrões de Projeto Comportamentais:
		
	 
	Interpreter, Chain of Responsibility e Observer
	
	Mediator, Strategy e Builder
	
	Singleton, Mediator e Strategy
	
	Command, Composite e Memento
	
	State, Flyweight e Decorator
		
	
	
	 10a Questão (Ref.: 201604352220)
	Acerto: 1,0  / 1,0
	(BACEN ¿ CESGRANRIO 2010) Um arquiteto de software estuda que padrões de projeto são apropriados para o novo sistema de vendas de uma empresa. Ele deve considerar que o padrão
		
	
	Bridge separa a construção de um objeto complexo de sua representação, de modo que o mesmo processo de construção possa criar diferentes representações.
	
	Builder garante que uma classe seja instanciada somente uma vez, fornecendo também um ponto de acesso global.
	
	Singleton separa uma abstração de sua implementação, de modo que os dois conceitos possam variar de modo independente.
	
	Template Method utiliza compartilhamento para suportar, eficientemente, grandes quantidades de objetos de granularidade fina.
	 
	Chain of Responsibility evita o acoplamento entre o remetente de uma solicitação e seu destinatário, dando oportunidade para mais de um objeto tratar a solicitação.