Padrões de Projeto descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas consequências. Um dos padrões de projeto mais utilizados é o padrão Adapter (adaptador), que tem como função:
Padrões de projeto são descrições de soluções prontas para
problemas específicos e frequentes de software, podendo
ser classificados de acordo com a natureza do problema que
solucionam. A classificação e a finalidade do padrão de
projeto Decorator são, respectivamente:
Um processo de desenvolvimento de software contém a descrição de uma abordagem para a construção de sofware. A UML (unified modeling language) é uma linguagem visual para especificar, documentar e construir os artefatos de sistemas orientados a objetos. Quanto ao ambiente de desenvolvimento de sistemas orientados a objetos, julgue o item a seguir.
GRASP (general responsibility assignment software patterns) consiste em um conjunto de sete padrões básicos para atribuir responsabilidades em projeto orientado a objetos: information expert, creator, controller, low coupling, high cohesion, polymorphism e pure fabrication.
Um Programador está desenvolvendo uma aplicação em que os objetos mudam de estado com muita frequência. Em tempo de execução, a mudança no estado lógico destes objetos implica também na alteração em seu comportamento. Nessa aplicação é ideal que o Programador utilize um design pattern comportamental cuja classe Context é a interface principal para as requisições dos clientes. O Programador deve utilizar o design pattern
I. Fornecer uma interface para criação de famílias de objetos relacionados ou dependentes, sem especificar suas classes concretas. Possibilitar o adiamento da instanciação para as subclasses.
II. Garantir a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
III. Possibilitar o armazenamento do estado interno de um objeto em um determinado momento, para que seja possível retorná-lo a este estado, caso necessário.
I, II e III são, respectivamente, objetivos dos design patterns intitulados:
Julgue os itens seguintes referentes a padrões de projeto.
Para um projetista de software estender um componente desenvolvido segundo o padrão Command, com a capacidade de desfazer operações sobre objetos complexos sem violar o encapsulamento de tais objetos, o mais adequado é usar, de forma complementar, o padrão Memento, em vez do padrão Visitor.
Considere que, em um documento de requisitos, foram
elencadas as seguintes necessidades a serem supridas por meio de
padrões de projeto:
I implementar um padrão de criação que possibilite a separação
entre a construção de um objeto complexo e sua representação
de modo que esse processo de construção possa criar diferentes
representações;
II implementar um padrão que evite vínculo permanente entre
uma abstração e sua implementação;
III implementar um padrão que, sem violar o encapsulamento e a
captura, externalize o estado interno de um objeto e permita
que posteriormente ele seja restaurado a esse estado;
IV implementar um padrão que permita a variação do algoritmo
independentemente dos clientes que o utilizam;
V implementar um padrão que forneça uma interface unificada
para um conjunto de interfaces em um subsistema;
VI implementar um padrão que especifique os tipos de objetos a
serem criados usando uma instância prototípica e crie novos
objetos copiando este novo protótipo.
Com base nessa situação hipotética, julgue o item a seguir, com relação aos padrões de projeto.
O padrão estrutural bridge resolve corretamente o que se pede
em II.
Com relação a padrões de projeto e GRASP, julgue os próximos itens.
Caso haja necessidade de fornecer aos usuários de um sistema diversas maneiras de realizar uma mesma tarefa, como, por exemplo, a partir de menu, barra de ferramentas ou menu pop-up, o padrão chain of responsibility será mais apropriado para esse fim que o padrão command.