Design Patterns - Revista easy .net Magazine 20 - Parte 2

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

O artigo trata do uso de Design Patterns (ou padrões de projetos). Os mesmos são técnicas que já foram utilizadas na resolução de problemas comuns no desenvolvimento de software.

Atenção: esse artigo tem um vídeo complementar. Clique e assista!

De que se trata o artigo

O artigo trata do uso de Design Patterns (ou padrões de projetos). Os mesmos são técnicas que já foram utilizadas na resolução de problemascomuns no desenvolvimento de software (por exemplo, garantir uma única instância de uma classe em toda a aplicação). Um padrão representa, basicamente, um conjunto de orientações possíveis de serem seguidas quando da ocorrência de um tipo de problema específico.


Em que situação o tema é útil

Design patterns podem ser úteis na resolução de uma série de problemas recorrentes dentro do desenvolvimento de software. Determinados tipos de situações costumam acontecer com certa regularidade em atividades relacionadas à construção de aplicações; o uso de padrões pode neste caso não apenas se traduzir em economia de tempo, como também conduzir a uma melhor estruturação dos sistemas que estão sendo elaborados.

Design Patterns - Utilizando padrões de projeto na construção de aplicações - Parte 2

No transcorrer de diversos projetos de software, será bastante comum que os desenvolvedores se deparem com a repetição de determinadas situações. Em casos como este, pode ser possível a existência de soluções para certos tipos de necessidades: ao conjunto de recomendações que representam um caminho para a resolução de um problema específico dá-se o nome de padrão de projeto/design pattern. Padrões são o resultado de experiências bem sucedidas (por outros desenvolvedores) durante a elaboração de sistemas, sendo que sua aplicação promove não apenas o uso de boas práticas, como também pode contribuir para uma melhor estruturação dos softwares que se baseiam nos mesmos.

Na edição passada, foi iniciada uma discussão a respeito do uso de padrões de projetos no desenvolvimento de aplicações. Foram apresentados os objetivos a que se prestam estes mecanismos, bem como mencionadas vantagens que tais práticas oferecem.

São inúmeros os benefícios advindos do uso de padrões. A escolha pelos design patterns mais apropriados a um determinado contexto pode resultar em economia de recursos, bem como numa melhor estruturação da aplicação que se está contribuindo e, consequentemente, em uma maior facilidade para a condução de atividades futuras de manutenção. Outro ponto positivo obtido a partir da utilização destas técnicas, está na forte ênfase no reuso de soluções cuja eficácia já foi demonstrada anteriormente.

Merece destaque o fato de que os patterns de maior difusão no desenvolvimento de software estão fundamentados em conceitos de orientação a objetos, sendo uma prática comum à representação dos mesmos em diagramas da linguagem UML. Devido a estas características, diversos padrões podem ser empregados sem maiores transtornos em linguagens e plataformas bem heterogêneas como C#, VB.NET, Java, C++, Delphi etc.

Os patterns apresentados nesta série de artigos pertencem a um agrupamento de 23 padrões, conhecidos como GoF. Esta sigla é uma abreviação do termo (“Gang of Four”), sendo uma referência ao trabalho pioneiro de quatro autores (Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides) e que culminou no lançamento do conhecido livro “Design Patterns: Elements of Reusable Object-Oriented Software” em meados da década de 1990. Por mais que as diversas técnicas apresentadas nesta publicação sejam baseadas em exemplos codificados em C++ e Smalltalk, o largo escopo coberto por tais soluções auxilia ainda hoje desenvolvedores de modernas tecnologias, como .NET e Java (em problemas cotidianos, que serão visto a seguir).

Considerando o tipo de problema a que se propõe solucionar, os patterns GoF podem ser classificados em:

• Padrões de criação: Abstract Factory, Builder, Factory Method, Prototype e Singleton;

• Padrões estruturais: Adapter, Bridge, Composite, Decorator, Façade, Flyweight e Proxy;

• Padrões comportamentais: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method e Visitor.

É importante ressaltar que a própria plataforma .NET teve diversos de seus componentes básicos construídos em conformidade com alguns padrões GoF (alguns casos serão apresentados em seções subsequentes).

A finalidade deste artigo é dar andamento à abordagem iniciada na edição anterior, sendo que serão explicados em maior profundidade os seguintes patterns GoF:

• Abstract Factory;

• Adapter;

• Decorator;

• Iterator;

• Memento;

• Prototype;

• Strategy;

• Template Method.

Nota do DevMan

UML (sigla em inglês para "Unified Modeling Language") é uma linguagem voltada à modelagem de componentes de software e que se baseia em conceitos de orientação a objetos. Trata-se de uma notação que disponibiliza uma série de diagramas, sendo o de classes um dos mais conhecidos (este que será utilizado para a demonstração dos diversos patterns descritos neste artigo).

Abstract Factory

O padrão de criação Abstract Factory (Figura 1) promove o uso de uma interface (ou classe abstrata) que estará envolvida na geração de famílias de objetos relacionados (ou mesmo dependentes entre si), sem que se especifiquem as classes concretas das instâncias que serão criadas.

Graças a estas características, o consumidor de uma Abstract Factory não precisará ter conhecimento de todas as classes concretas que implementam a mesma ou ainda, dos produtos retornados por tal Factory.

As instâncias correspondentes às fabricas de objetos e aos produtos propriamente ditos, serão obtidas basicamente a partir de implementações concretas de interfaces e classes abstratas: os critérios para definir quais elementos servirão de base para a geração de referência, dependerá geralmente de informações de configuração ou mesmo, de alguma informação fornecida por um usuário da aplicação.

Nota do DevMan

Classes concretas: são classes que possuem atributos, métodos, construtores etc. As mesmas podem ser instanciadas, ou seja, permite a criação de objetos a partir dela.

Classes abstratas: são classes que servem como modelos para outras classes. Não pode ser instanciada. Na prática, você deve fazer com que classes concretas herdem de classes abstratas. Métodos abstratos codificados em uma classe abstrata devem obrigatoriamente ser implementados em uma classe concreta.

Interface: é um tipo de recurso que define um conjunto de funcionalidades, sendo normalmente implementadas por classes. Declarações de métodos, propriedades e/ou eventos podem fazer parte de interfaces. Uma interface corresponde, em termos conceituais, a uma espécie de "contrato" ou "esqueleto", que serve de base para a construção de uma ou mais classes. Já uma classe pode implementar ao mesmo tempo mais de uma interface (a herança de múltiplas classes, contudo, não é possível dentro da plataforma .NET).

Nota

O próprio .NET framework emprega o padrão Abstract Factory dentro da tecnologia de acesso a dados ADO.NET: trata-se do tipo DbProviderFactory, o qual encontra-se definido no namespace System.Data.Common. Esta classe conta com funcionalidades para criação de objetos Connection, Command e DataAdapter, dentre outros elementos. As versões específicas da Factory e que correspondem ao uso dos drivers SQL Server ou Oracle serão implementadas, respectivamente, pelos tipos SqlClientFactory e OracleClientFactory.

"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?