Buscar

Padrões de Projeto em Engenharia de Software

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 4 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

Aula 6 – Padrões de Desenvolvimento 
 
Padrões de Projeto 
 
As ideias que deram origem aos padrões de projetos ocorreram em um contexto muito diferente da área de 
Engenharia de Software. 
 
Em 1977, o arquiteto Christopher Alexander e seus colegas publicaram o livro “A Pattern Language: Towns, Buidings, 
Construction”, uma espécie de catálogo com 253 (duzentos e cinquenta e três) padrões construtivos, argumentando 
que os métodos tradicionais utilizados pela arquitetura não supriam as reais necessidades dos usuários das 
construções propostas. 
 
E desta forma, segundo os autores, a arquitetura não atendia a sociedade como deveria, pois seu maior objetivo é 
melhorar a qualidade de vida das pessoas. Cada um dos padrões apresentados era como um pequeno manual sobre 
a questão arquitetônica: descrevia um determinado problema em um ambiente e o cerne de sua solução, de modo 
que essa solução pudesse ser utilizada várias vezes. 
 
Padrões são soluções de eficiência já comprovada e amplamente utilizadas para a resolução de problemas comuns 
em projeto de software. 
 
A aplicação de padrões é um exemplo de reuso de projeto, de ideias e soluções. O esforço extra gasto na fase de 
projeto é compensado pelos ganhos em flexibilidade e reuso. Devido à complexidade dos softwares desenvolvidos 
atualmente, os padrões de projetos facilitam muito a concepção dos sistemas. 
 
Os padrões de projetos facilitam a comunicação entre os desenvolvedores, facilitam a reutilização de projetos bem 
sucedidos, proporcionam uma maior tranquilidade quando for necessária a modificação de um projeto e tem 
documentado todas as suas características, aplicabilidades e soluções. 
 
Sendo assim, estudar e analisar padrões faz com que aprendamos com a experiência de outros na resolução de 
principais problemas e permitindo que façamos mais rapidamente projetos de melhor qualidade com soluções bem 
testadas e documentadas. 
 
Estrutura de um padrão de desenvolvimento 
 
Os principais atributos de uma boa descrição de um padrão de projeto são: 
 
Padrões GoF 
 
Em 1995, Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm descreveram 23 (vinte e três) padrões que 
podem ser aplicados ao desenvolvimento de sistemas de software orientados a objetos. 
 
Gamma e seus colaboradores são conhecidos como a Gangue dos Quatro (Gang of Four, GoF). 
 
Os padrões GoF formam um catálogo de boas decisões de projeto. Trata-se de documentação de soluções obtidas 
através da experiência. Foram coletados de experiências de sucesso na indústria de software, principalmente de 
projetos em C++® e SmallTalk®. 
 
Classificação dos 23 padrões segundo GoF 
 
São organizados em famílias de padrões, conforme o esquema: 
 
 
 
Criação - Relacionados à criação de objetos; 
Estrutura – Tratam das associações entre classes e objetos. Tratam de compor classes e objetos para formar 
estruturas grandes e complexas; 
Comportamento - Das interações e divisões de responsabilidades entre as classes ou objetos. 
 
Alguns exemplos 
 
 
 
Padrão Singleton 
 
Intenção 
 
Garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela. 
 
Motivação 
 
Garantir que exista um determinado número X de objetos de uma classe. 
 
Aplicabilidade 
 
Havendo a necessidade de existir apenas uma instância de uma classe e essa instância deve dar acesso aos clientes 
através de um ponto bem conhecido. 
 
Padrão Abstract Factory 
 
Intenção 
Fornecer uma interface para criação de objetos relacionados sem especificar as suas classes concretas. 
 
Motivação 
 
Considere uma aplicação com interface gráfica que é implementada para plataformas diferentes. As classes 
implementando os elementos gráficos não podem ser definidas estaticamente no código. Há necessidade de uma 
implementação diferente para cada ambiente. como, por exemplo, implementar diferentes aparências (look-and-
feels). 
 
Aplicabilidade 
 
Use uma fábrica abstrata quando: 
 
Um sistema deve ser independente da forma como seus produtos são criados e representados. 
 
 
 
Padrão Adapter 
Também conhecido como WRAPPER. 
 
Intenção 
 
Converter a interface de uma classe em outra interface, esperada pelos clientes. Permite que classes com interfaces 
incompatíveis trabalhem em conjunto. 
 
Motivação 
 
Algumas vezes uma classe não é reusavel porque sua interface não é compatível com a interface de uma aplicação 
de um domínio específico. A solução é criar um objeto adaptador, que encapsule e filtre as características peculiares 
da classe adaptada, fornecendo uma interface que a aplicação espera utilizar. 
 
Aplicabilidade 
 
Use o Padrão Adapter quando você quiser: 
 
Utilizar uma classe existente, e sua interface não for compatível com uma que você necessita. 
 
Criar uma classe reusável que coopera com classes não-relacionadas ou não previstas a priori, isto é, classes que não 
apresentam necessariamente interfaces compatíveis. 
 
Padrão Bridge 
Também conhecido como handle/Body. 
 
Intenção 
 
Desacoplar uma abstração de sua implementação, de modo que as duas possam variar independentemente. 
 
Motivação 
 
Quando uma abstração pode ter várias implementações, a solução usual é acomodar todas as implementações 
através de herança. No entanto, herança liga de forma permanente uma abstração a uma implementação. O padrão 
Bridge permite colocar as abstrações e suas implementações em diferentes hierarquias de classes, e permite que 
variem de forma independente. 
 
Aplicabilidade 
 
Use Quando Quiser evitar ligação permanente entre uma abstração e sua implementação. 
 
 
 
Padrão Observer 
 
Intenção 
 
Definir uma dependência de um para muitos com um mecanismo de notificação de eventos. 
 
Motivação 
 
A mesma informação (modelo) pode ser exibida em diferentes formatos (visão) em paralelo. 
 
Aplicabilidade 
 
Quando uma abstração apresenta dois aspectos, um dependente do outro. Encapsulando estes aspectos em objetos 
separados permite que você os varie e reutilize de forma independente. 
 
Padrão Strategy 
 
Intenção 
 
Define uma família de algoritmos, encapsula cada um, e os faz intercambiáveis. Permite que o algoritmo varie 
independentemente dos clientes que o utilizam. 
 
Motivação 
 
Alguns algoritmos se repetem com frequência, por isso devem ser isolados para facilitar a manutenção. 
 
Aplicabilidade 
 
Utilize quando alguns algoritmos se repetirem com frequência, por isso devem ser isolados para facilitar a 
manutenção.

Outros materiais