Baixe o app para aproveitar ainda mais
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.
Compartilhar