Design Patterns

BSI05

O trabalho trata de vários Design Patterns, e os define como "soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto nada mais é do que uma solução para esse determinado problema". No artigo foram citados vários Design Patterns, são eles: Singleton, Facade, Iterator, e MVC.

É feita a definição onde separa estes vários design patterns em duas categorias. Os do tipo do tipo GoF, ou Gang of Four que dividem os design patterns em 3 categorias: criação, estrutural e comportamentais. E os do tipo Grasp, ou "General Responsibility Assignment Software Patterns" que conforme afirma a equipe existem diversos padrões, porém eles abordaram somente um Design Patter Grasp Controller.

Iniciando as explicações de Design Patterns, o primeiro a ser apresentado foi o Sigleton, este serve para garantir que somente uma instânsia de uma classe exista mantendo um único ponto global de acesso ao seu objeto. A equipe defende que este tipo de prática não sobrecarrega a memória do sistema e faz a distinção entre o singleton contra os métodos estáticos e contra injeção de dependência. Onde o primeiro não é aconselhado o uso do singleton para essa situação e destaca que seu uso abre mão de algumas vantagens como a perda do polimorfismo. Porém não há nenhum exemplo de código que demonstre a situação e não há um levantamento das vantagens e desvantagens do uso do Singleton em relação a outros design patterns.

Em seguida é comentado sobre o FACADE, onde cita que o facade pode ser considerado um encapsulador de classes, onde o programa fáz o acesso a elas atravéz do próprio FACADE facilitando a arquitetura do projeto como um todo. Esclaresce que o FACADE é uma interface simplificada para uma classe mais complexa, e que na verdade não passa de uma organização da classe ordenando os seus métodos por funcionalidades ou outros critérios.

O último design patterns citado do tipo GoF é citado o ITERATOR. Ele é usado para que iteradores utilizados para acessar os elementos de um conjunto de objetos, não exponham a sua arquitetura nem a forma como os objetos são iterados. Porém não há uma definição de por que isso traria alguma vantagem ao desenvolvimento, assim não ficando claro o objetivo do ITERATOR.

Por fim define o MVC em Model, View e Controller e explica cada uma destas camadas. Citando que o Model contém os dados das aplicações e as regras de negócio que se associam a ela. View como a camada que o usuário interage diretamente. E por fim o Controller como que responde a eventos normalmente disparados pelo usuário atravéz de uma View.

Em geral o artigo apresenta vários Design Patterns, mas não mostra exemplos de código nem as aplicações deles em software conhecidos. Desta forma não fica claro o grau de efetividade na adoção destes como ferramenta de trabalho. Porém ele é bem útil para mostrar a existência de diversos design patters, assim como a sua divisão entre os dois tipos direferentes de padrões GoF e Grasp os quais não conheciamos.