Padrões de projeto em .NET: Adapter

Chegando aos padrões estruturais, este padrão, também conhecido como Wrapper, tem por objetivo converter a interface de uma classe em outra interface, esperada pelos clientes. O Adapter permite que classes com interfaces incompatíveis trabalhem em conjunto – o que, de outra forma, seria impossível.

Uma das motivações mais evidentes para a utilização deste padrão seja, talvez, o consumo de web services por outras tecnologias que não .NET, como Visual Baisc 6.0, por exemplo.

Considere, por exemplo, um web service que fornece a temperatura atualizada de todos os estados do país. Este web service foi desenvolvido com tecnologia .NET e fornece os resultados à aplicações que suportam a mesma tecnologia via XML. Porém, uma agência de turismo, que possui um sistema legado em Visual Basic 6.0 e está satisfeita com o mesmo, gostaria de utilizar as informações sem que seja necessária uma migração. Neste ponto entra o padrão Adapter.

Com este padrão, é possível criar uma classe que seja compatível com a tecnologia da agência de viagens (Visual Basic 6.0) e permita que a mesma utilize o web service que informa a temperatura atualizada nos estados do país (.NET). Além disso, a empresa responsável pelo web service não precisa abdicar da reutilização, que foi, provavelmente, a principal motivação para a criação do serviço, para fornecer suas informações.

Quando usar Adapter?

Use o padrão Adapter quando:

• Você quiserusar uma classe existente, mas sua interface não corresponder à interface de que necessita;
• Você quiser criar uma classe reutilizável que coopere com classes não-relacionadas ou não-previstas, ou seja, classes que não necessariamente tenham interfaces compatíveis;
• (Somente para adaptadores de objetos) Você precisar usar várias subclasses existentes, porém, for impraticável adaptar essas interfaces criando subclasses para cada uma. Um adaptador de objeto pode adaptar a interface da sua classe-mãe.

Estrutura

Um adaptador de classe usa a herança múltipla para adaptar uma interface à outra:

Um adaptador de objeto depende da composição de objetos:

• Alvo: define a interface específica do domínio que Cliente usa.
• Cliente: colabora com objetos compatíveis com a interface de Alvo.
• Adaptado: define uma interface existente que necessita ser adaptada.
• Adaptador: adapta a interface do Adaptado à interface de Alvo.

Conseqüências

Os adaptadores de classes e de objetos têm diferentes soluções de compromisso. Um adaptador de classe:

• Adapta o Adaptado ao Alvo através do uso efetivo de uma classe Adaptador concreta. Em conseqüência, um adaptador de classe não funcionará quando quisermos adaptar uma classe e todas as suas subclasses; ...

Padrões de projeto em .NET: Prototype

Este padrão foi criado com o objetivo de especificar os tipos de objetos a serem criados usando uma instância-protótipo e criar novos objetos pela cópia desse protótipo.

Você poderia construir um editor para partituras musicais customizando um framework geral para editores gráficos, adicionando novos objetos que representam notas, pausas e pentagramas. O editor do framework pode ter uma paleta de ferramentas para adicionar esses objetos de música à partitura. A paleta também incluiria ferramentas para selecionar, mover e manipular objetos de música de outra forma. O usuário clicaria na ferramenta de uma semínima para adicionar semínimas à partitura. Ou poderia usar a ferramenta de movimentação para mover uma nota para cima ou para baixo nas linhas de pauta, alterando seu registro sonoro.

Vamos considerar que o framework forneça uma classe abstrata Graphic para componentes gráficos, como notas e pentagramas. Além disso, fornece uma classe abstrata Tool para definir ferramentas como aquelas da paleta. O framework também predefine uma subclasse GraphicTool para ferramentas que criam instâncias de objetos gráficos e os adicionam ao documento.

Mas GraphicTool apresenta um problema para o projetista do framework. As classes para notas e pentagramas são específicas da nossa aplicação, mas a classe GraphicTool pertence ao framework. GraphicTool não sabe como criar instâncias das nossas classes musicais para adicioná-las à partitura. Poderíamos introduzir subclasses de GraphicTool para cada tipo de objeto musical que elas instanciam. Sabemos que composição de objetos é uma alternativa flexível para o uso de subclasses. A questão, porém, é: como pode um framework usá-la para parametrizar instâncias de GraphicTool pela classe de Graphic que se espera que elas criem?

A solução é fazer GraphicTool criar um novo Graphic copiando ou clonando uma instância de uma subclasse de Graphic. Chamamos esta instância de protótipo. A GraphicTool é parametrizada pelo protótipo que ela deveria clonar e adicionar ao documento. Se todas as subclasses de Graphic suportam uma operação Clone, então GraphicTool pode clonar qualquer tipo de Graphic.

Assim, em nosso editor musical, cada ferramenta para criar um objeto musical é uma instância de GraphicTool que é iniciada com um protótipo diferente. Cada instância de GraphicTool produzirá um objeto musical clonando o seu protótipo e adicionando o clone à partitura.

Quando usar Prototype?

Use o padrão Prototype quando um sistema tiver que ser independente de como os seus produtos são criados, compostos e representados; e:

• Quando as classes a instanciar forem especificadas em tempo de execução, por exemplo, por carga dinâmica;
• Para evitar a construção de uma hierarquia de classes de fábricas paralela à hierarquia de classes de produto;
• Quando as instâncias de uma classe puderem ter uma dentre poucas combinações diferentes de estados. Pode ser mais conveniente instalar um número correspondente de protótipos e cloná-los, ao invés de instanciar a classe manualmente, cada vez com um estado apropriado.

Estrutura

• ...

Como ligar dois controles diferentes a um mesmo DataTable sem que as alterações de dados realizadas por um controle alterem os dados no outro

Este é um problema bastante comum. Suponha que você tenha 2 controles, ComboBox e ListBox, no mesmo formulário e a propriedade DataSource de ambos é a mesma. Então, a seleção de um item em um controle seleciona o mesmo item no outro controle. Este problema ocorre por causa da propriedade BindingContext dos controles. Por padrão, o BindingContext dos 2 controles está configurada para levar em consideração o BindingContext do formulário. Logo, o comportamento padrão dos controles é compartilharem o mesmo BindingContext. E é por isso que as seleções ficam sincronizadas. Se você não deseja este comportamento, crie um novo BindingContext para, pelo menos, um dos controles.

 &

Validações úteis para TextBox

1. TextBox numérica

    Private Sub TextBox1_KeyPress(ByVal sender As Object, _

    ByVal e As System.Windows.Forms.KeyPressEventArgs) _

    Handles TextBox1.KeyPress

        If (Not (Char.IsDigit(e.KeyChar) _

        Or Char.IsControl(e.KeyChar))) Then

            e.Handled = True

        End If

    End Sub

2. TextBox numérica com decimais

    Private Sub TextBox1_KeyPress(ByVal sender As Object, _

    ByVal e As System.Windows.Forms.KeyPressEventArgs) _

    Handles TextBox1.KeyPress

        If (Not (Char.IsDigit(e.KeyChar) _

        Or Char.IsControl(e.KeyChar) _

        Or (e.KeyChar = Chr(46)))) Then

            e.Handled = True

        End If

    End Sub

3. TextBox permitindo somente caracteres alfabéticos

    Private Sub TextBox1_KeyPress(ByVal sender As Object, _

    ByVal e As System.Windows.Forms.KeyPressEventArgs) _

    Handles TextBox1.KeyPress

        If (Not (Char.IsLetter(e.KeyChar) Or _

Como recuperar valores únicos em um array

É uma solução esperta. Use uma hashtable e preencha os elementos do array como chaves da hashtable. Quando houver duplicidade de chaves, a hashtable vai, naturalmente, retornar uma exceção. Apenas pule aquele elemento e continue o preenchimento. Para implementar esta solução, utilize recursão para adicionar os elementos do array à hashtable e no bloco Catch chame a mesma função novamente com o próximo índice. Abaixo, o código:

    Private strObj() As String = {"A", "A", "B", "C", "C", "D", "E"}

    Private HTUnica As New Hashtable

    Private i As Integer = 0

    Public Sub TesteElementoUnico()

        EncontrarElementoUnico(0)

    End Sub

    Private Sub Enco

Como recuperar o índice de um caractere com a função Substring independentemente de seu case em uma frase

O método IndexOf da classe String é case-sensitive. Existem 2 maneiras possíveis de contornar este problema:

1. Converter o case da frase inteira e da substring para qualquer outro case e, então, achar o índice do caracter em particular.

 Dim strPrincipal As String = "A .net Magazine é bem informativa."

    Dim strSecundaria As String = "magazine"

    ' A linha abaixo retornará -1 quando o esperado é 7.

    Dim i As Integer = strPrincipal.IndexOf(strSecundaria)

Limpar todas as caixas de texto de um formulário

No ASP clássico, para limpar todas as caixas de texto de um formulário, bastava que, simplesmente, usássemos um botão "Reset" no mesmo. Às vezes isso funciona no ASP .NET, outras vezes, não.

Abaixo estão algumas maneiras de fazer isso:

1. Navegar pelos controles TextBox de um formulário - Basta criar uma subrotina "Reset", com o seguinte código, em C#:

Smart Navigation

Smart Navigation é uma funcionalidade pouco conhecida do Internet Explorer que possibilita que controles em seu web form mantenham, individualmente, o foco entre os postbacks, bem como permite que você diminua o efeito de renderizar enquanto você carrega uma nova página.

Para ligar esta funcionalidade, simplesmente configure a propriedade SmartNavigation da sua página ASPX para True. Você pode, também, aplicar esta propriedade para todas as páginas do projeto, adicionando a tag na seguinte localização no seu web.config:

<configuration>

<system.web>

<pages smartNavigation="true"/>

</system.web>

</configuration>

Note que o smart navigation funciona somente a partir do Internet Explorer 5, porém, o ASP .NET irá, automaticamente, detectar isso e servir o smart navigation somente para o browser que suportá-lo.

Padrões de projeto em .NET: Factory Method

Também conhecido como Virtual Constructor, este padrão tem por objetivo definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar. O Factory Method permite adiar a instanciação para subclasses.

Os frameworks usam classes abstratas para definir e manter relacionamentos entre objetos. Um framework é freqüentemente responsável também pela criação desses objetos.

Considere um framework para aplicações que possuem um cadastro de clientes. Duas abstrações-chave nesse framework são as classes Sistema e Cadastro. As duas classes são abstratas, e os clientes devem prover subclasses para realizar suas implementações específicas para a aplicação. Por exemplo, para criar uma aplicação para uma mecânica, definimos as classes SistemaMecanica e CadastroMecanica. A classe Sistema é responsável pela administração de Cadastros e irá criá-los conforme exigido – quando o usuário seleciona Consultar ou Novo, por exemplo, em um menu.

Uma vez que a subclasse Cadastro a ser instanciada é própria da aplicação específica, a classe Sistema não pode prever a subclasse de Cadastro a ser instanciada – a classe Sistema somente sabe quando um cadastro e não que tipo de Cadastro criar. Isso cria um dilema: o framework deve instanciar classes, mas ele somente tem conhecimento de classes abstratas, as quais não pode instanciar.

O padrão Factory Method oferece uma solução. Ele encapsula o conhecimento sobre a subclasse de Cadastro que deve ser criada e move este conhecimento para fora do framework.

As subclasses de Sistema redefinem uma operação abstrata CriarCadastro em Sistema para retornar a subclasse apropriada de Cadastro. Uma vez que uma subclasse de Sistema é instanciada, pode, então, instanciar Cadastros específicos da aplicação sem conhecer suas classes. Chamamos CriarCadastro um factory method porque ele é responsável pela “manufatura” de um objeto.

Quando usar Factory Method?

Use o padrão Factory Method quando:

• Uma classe não pode antecipar a classe de objetos que criam;
• Uma classe quer que suas subclasses especifiquem os objetos que criam;
• As classes delegam responsabilidade para uma dentre várias subclasses auxiliares, e você quer localizar o conhecimento de qual subclasse auxiliar que é a delegada 

Estrutura

• Produto (Cadastro): define a interface de objetos que o método fábrica cria.
• ...

Padrões de projeto em .NET: Builder

A intenção deste padrão é separar a construção de um objeto complexo da sua representação de modo que o mesmo processo de construção possa criar diferentes representações.

Como motivação para utilização deste padrão, utilizaremos o exemplo de uma fábrica de persianas. Uma fábrica de persianas vende 3 tipos de produtos: persianas horizontais, persianas verticais e black outs. Cada um destes produtos tem especificações de fabricação diferentes. Por exemplo: uma persiana vertical deve ter suas lâminas fabricadas na posição vertical, além de ser acompanhada, opcionalmente, por um bandô, que fica colocado acima da persiana, cobrindo seu trilho. Além disso, seus comandos devem fazer as lâminas correrem pelo trilho, de uma lado ao outro, ou girá-las 180 graus horizontalmente. No caso da persiana horizontal, não há bandô, suas lâminas são fabricadas em posição horizontal e seus comandos permitem que as lâminas subam ou desçam, ou girem 180 graus na vertical. Quando se trata de um black out, suas lâminas são fabricadas em posição vertical, maiores em largura e seus comandos permitem que as lâminas percorram o trilho de um lado ao outro, porém, não girem. O black out também tem a opção do bandô. Além disso, caso haja a possibilidade de fabricação de uma persiana de especificações diferentes às 3 anteriores, deve ser fácil acrescentar este novo produtor sem afetar o construtor.

Uma solução é configurar a classe Fabrica com um objeto Persiana que é responsável por construir os 3 tipos de persianas. À medida que a Fabrica recebe solicitações para a construção de persianas, ele usa o objeto Persiana para realizar esta construção. Os objetos Persiana são responsáveis tanto por construir as persianas quanto por representá-las sob diferentes especificações.

As subclasses de Persiana se especializam em diferentes especificações. Por exemplo: um PersianaVertical ignora solicitações de construção de qualquer tipo de persiana, exceto a persiana vertical. Por outro lado, um PersianaHorizontal implementará operações para todas as solicitações visando construir persianas horizontais. Por fim, um BlackOut produzirá um objeto para a construção de black outs.

Cada tipo de classe construtora implementa o mecanismo para a criação e montagem de um objeto complexo, colocando-o atrás de uma interface abstrata. O construtor é separado da fábrica, que é responsável pela análise da solicitação de construção de uma persiana.

O padrão Builder captura todos estes relacionamentos. Cada classe construtora é chamada um builder no padrão, e o leitor é chamado de director. Aplicado a este exemplo, o Builder separa o algoritmo para interpretar uma solicitação de construção de uma persiana (isto é, a fábrica de persianas) de como a persiana solicitada é construída e representada. Isso nos permite reutilizar o algoritmo de análise (parsing) da Fabrica para criar diferentes persianas – simplesmente configure a Fabrica com diferentes subclasses de Persiana.

Quando usar Builder?

Use o padrão Builder quando:

• O algoritmo para criação de um objeto complexo deve ser independente das partes que compõem o objeto e de como elas são montadas;
• O processo de construção deve permitir diferentes representações para o objeto que é construído

Estrutura

• Builder (Persiana): especifica uma interface abstrata para criação de partes de um objeto.
• BuilderConcreto (PersianaVertical, PersianaHorizontal, BlackOut): constrói e monta partes do objeto pela implementação da interface Builder; define e mantém a representação que cria e fornece uma interface para recuperação do produto (por exemplo, RecuperarPersianaVertical, RecuperarPersianaHorizontal).
• Director (Fabrica): constrói um objeto usando a interface de Builder.
• Produto (objetos de PersianaVertical, PersianaHorizontal e BlackOut): representa o objeto complexo em construção; inclui classes que definem as partes constituintes, inclusive as interfaces ...

Padrões de projeto em .NET: Abstract Factory

Também conhecido como Kit, este padrão fornece uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

Para esclarecer a motivação para utilização deste padrão, considere a construção de um carro. Ao escolher um carro de uma determinada marca e modelo, um comprador sabe que está levando para casa, obrigatoriamente, determinadas peças. Porém, ele sabe, também, que itens como cor, airbag e direção hidráulica são itens opcionais, ou seja, podem estar presentes no carro a ser comprado ou não, influenciando em seu preço. Para ser portátil entre as várias opções, uma aplicação não deve codificar rigidamente seus componentes para um determinado padrão. Instanciando classes específicas de personalização pela aplicação toda torna difícil mudar tal personalização no futuro.

Podemos resolver esse problema definindo uma classe abstrata CarroFactory que declara uma interface para criação de cada tipo básico de carro. Existe, também, uma classe abstrata para cada tipo de carro, e subclasses concretas implementam os componentes para personalização. A interface de CarroFactory tem uma operação que retorna um novo objeto Carro para cada classe abstrata de Carro. Os clientes chamam estas operações para obter instâncias de Carro, mas não têm conhecimento das classes concretas que estão usando. Desta forma, os clientes ficam independentes do padrão de personalização usado no momento.

Existe uma subclasse concreta de CarroFactory para cada tipo de personalização. Cada subclasse implementa as operações para criar o carro apropriado para aquele tipo de personalização. Por exemplo, a operação CriarMotor aplicada à PoloCarroFactory instancia e adiciona um componente motor ao carro, de acordo com os padrões Volkswagen para o modelo Polo, enquanto que a mesma operação aplicada à StiloCarroFactory instancia um componente motor ao carro de acordo com os padrões Fiat para o modelo Stilo. Os clientes criam componentes exclusivamente através da interface de CarroFactory e não têm conhecimento das classes que implementam os componentes para um padrão específico. Em outras palavras, os clientes têm somente que se comprometer com uma interface definida por uma classe abstrata, não uma determinada classe concreta. Uma CarroFactory também implementa e garante as dependências entre as classes concretas de componentes. Um motor para o modelo Volkswagen Polo deveria ser usado somente com um carro modelo Volkswagen Polo, e essa restrição é garantida automaticamente como conseqüência de usar uma PoloCarroFactory

Quando usar Abstract Factory?

Use o padrão Abstract Factory quando:

• Um sistema deve ser independente de como seus produtos são criados, compostos ou representados;
• Um sistema deve ser configurado como um produto de uma família de múltiplos produtos;
• Uma família de objetos for projetada para ser usada em conjunto, e você necessita garantir esta restrição;
• Você quer fornecer uma biblioteca de classes e quer revelar somente suas interfaces, não suas implementações.

Estrutura

• AbstractFactory (CarroFactory): Declara uma interface para a criação de objetos abstratos.
• ConcreteFactory (PoloCarroFactory, StiloCarroFactory): Implementa as operações que criam objetos concretos.
• AbstractProduct (Motor): Declara uma interface para um tipo de objeto.
• ConcreteProduct (MotorPolo, MotorStilo): Define um objeto a ser criado pela fábrica concreta correspondente e implementa a interface de AbstractProduct.
• Client: Utiliza somente as interfaces declaradas pelas classes AbstractFactory e AbstractProduct.

Vantagens e desvantagens

O padrão Abstract Factory tem as seguintes vantagens e desvantagens:

• Ele isola as classes concretas. O padrão Abstract Factory ajuda a controlar as classes de objetos criadas por uma aplicação. Uma vez que a fábrica encapsula a responsabilidade e o processo de criar objetos, isola os clientes das classes de implementação. Os clientes manipulam as instâncias através das suas interfaces abstratas. Nomes de classes ficam isolados na implementação da fábrica concreta.
• Ele torna fácil a troca de famílias de produtos. A classe de uma fábrica concreta aparece apenas uma vez numa aplicação, isto é, quando é instanciada. Isso torna fácil mudar a fábrica concreta que uma aplicação usa. Ela pode usar diferentes configurações de objetos simplesmente trocando a fábrica concreta. Uma vez que a fábrica abstrata cria uma família completa de objetos, toda família de objetos muda de uma só vez. No nosso exemplo de construção de carros, podemos mudar de componentes do Polo para componentes do Stilo simplesmente trocando as correspondentes fábricas e recriando o carro.
• Ela promove a harmonia entre produtos. Quando objetos numa família são projetados para trabalharem juntos, é importante que uma aplicação use objetos de somente uma família de cada vez. Abstract Factory torna fácil assegurar isso.
• É difícil suportar novos tipos de produtos. Estender fábricas abstratas para produzir novos tipos de produtos não é fácil. Isso se deve ao fato de que a interface de Abstract Factory fixa o conjunto de produtos que podem ser criados. Suportar novos tipos de produtos exige estender a interface da fábrica, o que envolve mudar a classe AbstractFactory e todas as suas subclasses.

Exemplo de código

Aplicaremos o padrão AbstractFactory para criar os carros que discutimos no início do artigo.

A classe CarFactory pode criar modelos de carros e seus respectivos componentes. Ela define motor, pneu, porta, entre outros. Esta classe pode ser usada por uma aplicação que lê as especificações de um determinado modelo de carro em um arquivo XML, por exemplo, e constrói o respectivo carro, ou pode ser usada por uma aplicação que constrói carros aleatoriamente. As aplicações que constroem os carros recebem CarFactory como parâmetro, de maneira que o desenvolvedor possa especificar as classes de motor, pneu e porta a serem construídas.

Public Interface ICarroFactory

    Function CriarCarro() As ICarro

    Function CriarMotor() As IMotor

    Function CriarPneu() As IPneu

    Function CriarPorta() As IPorta

End Interface

Vale frisar que a função MontarCarro cria um carro básico, consistindo em 2 portas, 4 pneus e 1 motor. É claro que estes itens não são suficientes para que um carro funcione. Porém, a intenção, aqui, é exemplificar a utilização do padrão AbstractFactory.

Public

Padrões de projeto em .NET - Introdução

O que é um padrão de projeto?

Segundo Christopher Alexander, “cada padrão descreve um problema no nosso ambiente e o cerne da sua solução, de tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca faze-lo da mesma maneira”. Embora Alexander estivesse se referindo a padrões em construções e cidades, o que ele diz é perfeitamente aplicável quando falamos em padrões de projetos orientados a objeto. Nossas soluções são expressas em termos de objetos e interfaces em vez de paredes e janelas, mas no coração de ambos os tipos de padrões está a solução para um problema em um determinado contexto.

Catálogo de padrões de projeto

O catálogo abaixo contém 23 padrões de projeto. Seus nomes e intenções são listados para dar uma visão geral.

Abstract Factory: Fornece uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas.

Adapter: Converte a interface de uma classe em outra interface esperada pelos clientes. O Adapter permite que certas classes trabalhem em conjunto, pois de outra forma seria impossível por causa de sua interfaces incompatíveis.

Bridge: Separa uma abstração da sua implementação, de modo que as duas possam variar independentemente.

Builder: Separa a construção de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações.

Chain of Responsibility: Evita o acoplamento do remetente de uma solicitação ao seu destinatário, dando a mais de um objeto a chance de tratar a solicitação. Encadeia os objetos receptores e passa a solicitação ao longo da cadeia até que um objeto a trate.

Command: Encapsula uma solicitação como um objeto, permitindo que você parametrize clientes com diferentes solicitações, enfileire ou registre solicitações e suporte operações que podem ser desfeitas.

Composite: Compõe objetos em estrutura de árvore para representar hierarquias do tipo parte-todo. O Composite permite que os clientes tratem objetos individuais e composições de objetos de maneira uniforme.

Decorator: Atribui responsabilidades adicionais a um objeto dinamicamente. Os decorators fornecem uma alternativa flexível a subclasses para extensão da funcionalidade.

Facade: Fornece uma interface unificada para um conjunto de interfaces em um subsistema. O Facade define uma interface de nível mais alto que torna o subsistema mais fácil de usar.

Factory Method: Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe a ser instanciada. O Factory Method permite a uma classe postergar a instanciação às subclasses.

Flyweight: Usa compartilhamento para suportar grandes quantidades de objetos, de granularidade fina, de maneira eficiente.

Interpreter: Dada uma linguagem, define uma representação para sua gramática juntamente com um interpretador que usa a representação para interpretar sentenças nessa linguagem.

Iterator: Fornece uma maneira de acessar seqüencialmente os elementos de uma agregação de objetos sem expor sua representação subjacente.

Mediator: Define um objeto que encapsula a forma como um conjunto de objetos interage. O Mediator promove o acoplamento fraco ao evitar que os objetos se refiram explicitamente uns aos outros, permitindo que você varie suas interações independentemente.

Memento: Sem violar o encapsulamento, captura e externaliza um estado interno de um objeto, de modo que o mesmo possa, posteriormente, ser restaurado para este estado.

Observer: Define uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são automaticamente notificados e atualizados.

Prototype: Especifica os tipos de objetos a serem criados usando uma instância prototípica e cria novos objetos copiando esse protótipo.

Proxy: Fornece um objeto representante, ou um marcador de outro objeto, para controlar o acesso ao mesmo.

Singleton: Garante que uma classe tenha somente uma instância e fornece um ponto global de acesso a ela.

State: Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá ter mudado de classe.

Strategy: Define uma família de algoritmos, encapsula cada um deles e os torna intercambiáveis. O Strategy permite que o algoritmo varie independentemente dos clientes que o utilizam.

Template Method: Define o esqueleto de um algoritmo em uma operação, postergando a definição de alguns passos para subclasses. O Template Method permite que as subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura.

Visitor: Representa uma operação a ser executada sobre os elementos da estrutura de um objeto. O Visitor permite que você defina uma nova operação sem mudar as classes dos elementos sobre os quais opera.

Organizando o catálogo

Os padrões de projeto variam na sua granularidade e no seu nível de abstração. Como existem muitos padrões de projeto, precisamos organizá-los. A classificação ajuda a aprender os padrões mais rapidamente, bem como direcionar esforços na descoberta de novos.

Os padrões de projeto são classificados por dois critérios: O primeiro critério, chamado finalidade, reflete o que o padrão faz. Os padrões podem ter finalidade de criação, estrutural ou comportamental. Os padrões de criação se preocupam com o processo de criação de objetos. Os padrões estruturais lidam com a composição de classes ou de objetos. Os padrões comportamentais caracterizam as maneiras pelas quais classes ou objetos interagem e distribuem responsabilidades.

O segundo critério, chamado escopo, especifica se o padrão se aplica primariamente a classes ou a objetos. Os padrões para classes lidam com os relacionamentos entre classes e suas subclasses. Esses relacionamentos são estabelecidos através do mecanismo de herança, assim eles são estáticos. Os padrões para objetos lidam com relacionamentos entre objetos que podem ser mudados em tempo de execução e são mais dinâmicos. Quase todos utilizam a herança em certa medida.

Boas vindas a Rafael Nascimento

Primeiramente, gostaria de agradecer a Deus, por ter me dado a capacidade de aprender e, em segundo lugar, ao Eduardo Spínola, pela oportunidade de ocupar o posto de colunista do portal de uma das maiores revistas de conteúdo técnico do país, a MSDN Magazine. Espero conseguir estar sempre atraindo os olhos do leitor e dar a minha contribuição para tornar este portal cada vez mais popular na comunidade técnica.

Em 1998 tive o meu primeiro contato com a tecnologia, setor o qual eu não tinha a mínima vontade de fazer parte. Estava começando o 1º ano do segundo grau técnico em processamento de dados (PD). Precisei fazer esta escolha no ano anterior. Muitos dos meus colegas fariam o PD e eu não via muito proveito no científico. Além disso, o científico da minha escola era bem fraco. Confesso que entender os algoritmos foi um show de horrores, mas com o t