Por que eu devo ler este artigo: Neste terceiro artigo da série de design patterns, vamos abordar agora os padrões de factory, que nos auxiliarão a não mais depender explicitamente de classes concretas, nos ajudando a manter o software menos acoplado.

Já vimos no primeiro artigo o que são design patterns, porque utilizá-los e vimos um dos padrões mais utilizados, o Strategy. No segundo artigo estudamos o padrão Template Method e o padrão Decorator. Com o primeiro vimos que podemos encapsular também algoritmos e garantir que os passos necessários à execução deste algoritmo serão implementados. O segundo nos mostrou como compor comportamentos de maneira aditiva, sem precisar alterar classes já prontas. Vimos também exemplos do mundo real para todos os padrões, assim como o próprio .Net Framework faz uso de algum deles.

Os problemas do “new”

Toda vez que escrevemos “new” em nosso código estamos instanciando um novo objeto. Aprendemos isso logo nos primeiros contatos com a programação. O que não nos é explicado de imediato (e às vezes não é explicado nunca) são os problemas que o “new” traz. Ao escrever: Dim n1 As New Ninja()

Estamos declarando uma nova variável do tipo Ninja, e associando a ela a referência a um novo objeto do tipo Ninja. Neste momento, estamos criando uma dependência direta entre o código sendo escrito e o tipo Ninja. A dependência pode não ser problema se estivermos trabalhando com um objeto simples, que não herda ou terá herdeiros e se não faremos uso de polimorfismo. Por outro lado, se o objeto faz parte de uma hierarquia de herança significativa, devemos buscar trabalhar com sua interface (seja ela realmente uma interface .Net ou uma classe base). Dessa forma, se por acaso a classe Ninja herda de uma classe Lutador, e queremos na verdade manipular esta classe base no software, trabalhar com uma dependência direta a Ninja pode nos trazer problemas. Se por acaso quisermos mudar de um Ninja para um Espadachim, pode ser que tenhamos que fazer uma grande manutenção no software, ou repetir uma grande quantidade de linhas de código.

Nota: Sempre que, neste artigo, ler interface, entenda como uma interface de comunicação, seja ela uma interface do .Net ou uma classe base.

Nesse momento você pode estar pensando: “Não há outra maneira de criar um objeto, senão com ‘new’”. Isso é verdade se considerarmos que essa é a construção básica e única para a criação de objetos no Visual Basic, assim como o é no C#, no Java e em tantas outras linguagens de programação. Mas não é verdade se considerarmos que um objeto pode ser instanciado com esta palavra-chave e passado como referência para outros objetos. Neste caso, os objetos que recebem a referência do objeto criado nunca utilizaram a palavra-chave “new”, mas ainda assim estão trabalhando o novo objeto criado.

Assim, em vez de codificar algo do tipo: Dim n1 As New Ninja()

Podemos construir algo assim: Dim n2 As Ninja = RetornaNinja()

Assumindo-se que a função RetornaNinja efetivamente nos retorna um objeto do tipo Ninja, teríamos em n2 um Ninja para realizar o que fosse necessário sem nunca termos utilizado “ ...

Quer ler esse conteúdo completo? Tenha acesso completo