17 de jun. de 2008
Aula 23 e 24
Padrão Command
Padrão command (Action ou Transaction) encapsula requisição a um objeto, gerar logs de comando executados, permite desfazer o que foi feito ou executado esse procedimento é também conhecido como RollBack e por fim, faz uso de classes de terceiros permitindo o uso de métodos que não foi você que criou, ou seja, na sua classe você pode utilizar outras classes ou métodos que estão criados há algum tempo, o padrão command nos permite essa flexibilidade e reusabilidade, a vantagem é poder reduzir o acoplamento entre as requisições dos clientes e os objetos que as executam.
Alguns padrões estão relacionados com o Command:
Composite pode ser usado para implementar MacroCommands.
Memento pode manter estados que o comando necessita para desfazer o seu efeito.
Um comando que deve ser copiado antes de ser colocado na lista histórica funciona como um Prototype.
Além dos padrões que foram relacionados acima, podemos citar outros que no decorrer da implementação irão surgindo de acordo com a necessidade, podendo aparecer o padrão Observer, Adapter, etc., de uma forma geral os padrões estão relacionados uns com outros tornando assim a interação entre eles.
Padrão command (Action ou Transaction) encapsula requisição a um objeto, gerar logs de comando executados, permite desfazer o que foi feito ou executado esse procedimento é também conhecido como RollBack e por fim, faz uso de classes de terceiros permitindo o uso de métodos que não foi você que criou, ou seja, na sua classe você pode utilizar outras classes ou métodos que estão criados há algum tempo, o padrão command nos permite essa flexibilidade e reusabilidade, a vantagem é poder reduzir o acoplamento entre as requisições dos clientes e os objetos que as executam.
Alguns padrões estão relacionados com o Command:
Composite pode ser usado para implementar MacroCommands.
Memento pode manter estados que o comando necessita para desfazer o seu efeito.
Um comando que deve ser copiado antes de ser colocado na lista histórica funciona como um Prototype.
Além dos padrões que foram relacionados acima, podemos citar outros que no decorrer da implementação irão surgindo de acordo com a necessidade, podendo aparecer o padrão Observer, Adapter, etc., de uma forma geral os padrões estão relacionados uns com outros tornando assim a interação entre eles.
Aula 21 e 22
Padrão - Observer
Observador define dependência 1 para n entres objetos, fazendo com que quando um objeto muda de estado todos seus dependentes são modificados e atualizados espontaneamente. Situação usual onde você tem um estoque central onde as suas revendas façam consulta a esse estoque quando uma franquia fecha negocio e da baixa no estoque automaticamente todas as franquias recebem aquela informação automaticamente ja que estão ligados diretamente a aquele estoque. O padrão Observer descreve uma forma de manutenção destes relacionamentos de modo que observadores e repositórios sejam facilmente substituídos.
1. Método Add
2. Método Remove
3. Método Notify
Observador define dependência 1 para n entres objetos, fazendo com que quando um objeto muda de estado todos seus dependentes são modificados e atualizados espontaneamente. Situação usual onde você tem um estoque central onde as suas revendas façam consulta a esse estoque quando uma franquia fecha negocio e da baixa no estoque automaticamente todas as franquias recebem aquela informação automaticamente ja que estão ligados diretamente a aquele estoque. O padrão Observer descreve uma forma de manutenção destes relacionamentos de modo que observadores e repositórios sejam facilmente substituídos.
1. Método Add
2. Método Remove
3. Método Notify
Aula 19 e 20
Padrão Singleton
Singleton, é um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.
Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.
Singleton, é um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.
Muitos projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em toda a aplicação que é acessível unicamente através da classe singleton.
Aula 17 e 18
Padrões GoF
Os padrões "GoF" são organizados em famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos. Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução. Padrões "GoF" organizados nas suas famílias:
Padrões de criação
Abstract Factory
Builder
Factory
Method Prototype
Singleton
Padrões estruturais
Adapter
Bridge
Composite
Decorator
Facade
Flyweight Proxy
Padrões comportamentais
Chain of Responsability
Command Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Os padrões "GoF" são organizados em famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos. Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução. Padrões "GoF" organizados nas suas famílias:
Padrões de criação
Abstract Factory
Builder
Factory
Method Prototype
Singleton
Padrões estruturais
Adapter
Bridge
Composite
Decorator
Facade
Flyweight Proxy
Padrões comportamentais
Chain of Responsability
Command Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
Aula 15 e 16
Alta Coesão
Alta coesão mostra qual o nivel de relacionamento entre as classe,
cujo as ligações formadas entre eles,toda vez que se tem uma alta
coesão fica mais facil de estar efetuando a manutenção com a alta
coesão o acoplamento diminui reduzindo a ligação entre varias
classes facilitando a possivel modificação futura sem ter que refazer
todas as ligações
Baixa Coesão
Existem varios problemas em se ter baixa coesão:
O dificil entendimento ja que os metodos estão misturados em uma mesma classe.
Sua reutilidade ja que não se tem o controle existem muitas classes onde uma mudança em uma delas pode acarretar em uma mudança geral no sistema
Como solucionar esse problema:
procurar criar classes independentes para que se possa
dar manutenção separadamente ou seja procurar sempre usar alta coesão
Alta coesão mostra qual o nivel de relacionamento entre as classe,
cujo as ligações formadas entre eles,toda vez que se tem uma alta
coesão fica mais facil de estar efetuando a manutenção com a alta
coesão o acoplamento diminui reduzindo a ligação entre varias
classes facilitando a possivel modificação futura sem ter que refazer
todas as ligações
Baixa Coesão
Existem varios problemas em se ter baixa coesão:
O dificil entendimento ja que os metodos estão misturados em uma mesma classe.
Sua reutilidade ja que não se tem o controle existem muitas classes onde uma mudança em uma delas pode acarretar em uma mudança geral no sistema
Como solucionar esse problema:
procurar criar classes independentes para que se possa
dar manutenção separadamente ou seja procurar sempre usar alta coesão
Assinar:
Postagens (Atom)