Variações Protegidas
Toda aplicação tem pontos de variação, identifique os pontos de variação ou instabilidade prevista, atribuindo responsabilidades para criar uma interface estável em torno deles. Na variação protegida temos as variações evolutivas e as variações corretivas.
Máquinas Virtuais – simulam vários sistemas em um único meio físico, dá maior portabilidade aos sistemas em ambientes instáveis.
Projetos dirigidos por interpretadores – são aplicações que interpretam ambientes ou sistemas diferentes, por exemplo JVM, Engine Regras.
Agentes (Brokers) – é encarregado de levar as requisições que recebe, localiza qual local de destino e entrega ao local correto.
Princípios da substituição de Liskov – como mecanismo de variação protegida a substituição de Liskov prevê que se declararmos classes como interface qualquer classe poderá implementar a superclasse.
XP – Extreme Programming
XP, ou Extreme programming, é uma metodologia para desenvolvimento de softwares ágil porém com qualidade indicada para projetos cujos requisitos mudem bastante, utilizam desenvolvimento orientado a objetos e tenham uma equipe de até 12 desenvolvedores. XP enfatiza o envolvimento do cliente e promove o trabalho em equipe.
4 focos principais
comunicação - ao extremo entre cliente e equipe, decisão mútua do que deve ser feito primeiro e o que pode ser deixado pra depois;
simplicidade - manter a simplicidade através do reuso de código e minimizando a construção de código;
feedback - pequenos releases e testes contínuos como mecanismo de retroalimentação;
coragem - ser honesto em dizer o que pode ser feito e o que não pode ser feito.
Bibliografia
Microsoft Corporation Groups, GRASP - Padrões de Software para Atribuição de Responsabilidade Gerais, Disponível em:<http://groups.msn.com/cafedotnet/grasppadresdesoftware.msnw>
Vivendo e Aprendendo
sábado, 21 de junho de 2008
Aula 29 e 30 de Projetos Orientado a Objetos
Invenção Pura
Faz uso das classes de domínio para ser implementada, surge nessa implementação um problema que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento". Para resolver esse problema podemos aplicar o conceito de uma classe Artificial ou inventada ela, não é uma classe de domínio por isso podemos associá-la com outras classes que são de domínio para resolver o problema de Alto Acoplamento e Baixa Coesão, atribuindo a ela responsabilidades coesas. Algumas das vantagens são:
Diminui o Acoplamento;
Diminui a pulverização de código e,
Aumenta a coesão.
O principal objetivo de se usar Indireção, é que podemos atribuir a responsabilidade a um objeto intermediário que faz mediação entre os outros componentes ou serviços de modo que eles não estejam diretamente acoplados. O objeto intermediário cria uma camada de indireção entre os dois componentes que não dependem um do outro: agora ambos dependem da indireção.
O Spring é um framework open source criado por Rod Johnson e descrito em seu livro "Expert One-on-One: J2EE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos. Esse framework foi criado para que ele se conecte com outros frameworks, IoC (Inversão de Controle) não é a aplicação que controla, o controle ta fora da aplicação.
O spring não suporta interceptação de campos, apenas de métodos.
Um exemplo clássico de utilização transparente do suporte a AOP do spring framework, é o gerenciamento de transações declarativas nativo do Spring, que é implementado como um Advice AOP.
Bibliografia
Wikimedia Foundation, Inc, Spring Framework, Disponível em: <http://en.wikipedia.org/wiki/Spring_framework> Acessado em 06Junho 2008, 18:20;
GRASP Patterns, Disponível em:<http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt> Acessado em 06 Junho 2008, 18:20;
Faz uso das classes de domínio para ser implementada, surge nessa implementação um problema que objeto deve ter a responsabilidade quando você não quer violar "Alta Coesão" e "Baixo Acoplamento". Para resolver esse problema podemos aplicar o conceito de uma classe Artificial ou inventada ela, não é uma classe de domínio por isso podemos associá-la com outras classes que são de domínio para resolver o problema de Alto Acoplamento e Baixa Coesão, atribuindo a ela responsabilidades coesas. Algumas das vantagens são:
Diminui o Acoplamento;
Diminui a pulverização de código e,
Aumenta a coesão.
O principal objetivo de se usar Indireção, é que podemos atribuir a responsabilidade a um objeto intermediário que faz mediação entre os outros componentes ou serviços de modo que eles não estejam diretamente acoplados. O objeto intermediário cria uma camada de indireção entre os dois componentes que não dependem um do outro: agora ambos dependem da indireção.
O Spring é um framework open source criado por Rod Johnson e descrito em seu livro "Expert One-on-One: J2EE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos. Esse framework foi criado para que ele se conecte com outros frameworks, IoC (Inversão de Controle) não é a aplicação que controla, o controle ta fora da aplicação.
O spring não suporta interceptação de campos, apenas de métodos.
Um exemplo clássico de utilização transparente do suporte a AOP do spring framework, é o gerenciamento de transações declarativas nativo do Spring, que é implementado como um Advice AOP.
Bibliografia
Wikimedia Foundation, Inc, Spring Framework, Disponível em: <http://en.wikipedia.org/wiki/Spring_framework> Acessado em 06Junho 2008, 18:20;
GRASP Patterns, Disponível em:<http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt> Acessado em 06 Junho 2008, 18:20;
Aula 27 e 28 de Projetos Orientado a Objetos
Padrões GRASP
O polimorfismo torna o código mais legível, mais enxuto e facilita a manutenção dos sistemas pois permite que se utilize métodos com o mesmo nome para objetos diferentes. A mesma operação, que foi implementada através da codificação de um método, pode atuar de modo diferente em classes diferentes.
1º - Evitar a condição IF e ELSE
2º - Usar polimorfismo melhorar a conectividade dos componentes
A solução de alguns problemas do polimorfismo tais como criar componentes de softwares conectáveis, é atribuir responsabilidade aos tipos para os quais o comportamento varia, usando operações polimórficos.
Framework – ao contrário da ferramenta ToolKit no framework o desenvolvedor terá que utilizar o roteiro do jeito que está definido na ferramenta, existem vários tipos de frameworks, alguns deles são:
Spring é um framework open source criado por Rod Johnson e descrito em seu livro "Expert One-on-One: J2EE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos. Esse framework foi criado para que ele se conecte com outros frameworks, IoC (Inversão de Controle) não é a aplicação que controla, o controle ta fora da aplicação.
Bibliografia
Jacques Philippe Sauvé, http://walfredo.dsc.ufcg.edu.br/cursos/2002/progII20021/aulas/o_que_e_polimorfismo.htm>
<http://w3.ualg.pt/~hdaniel/poo/teorica/poot03.pdf> <http://imasters.uol.com.br/artigo/4497/spring_framework_introducao>
Contegix, Disponível em: <http://www.springframework.org/>
O polimorfismo torna o código mais legível, mais enxuto e facilita a manutenção dos sistemas pois permite que se utilize métodos com o mesmo nome para objetos diferentes. A mesma operação, que foi implementada através da codificação de um método, pode atuar de modo diferente em classes diferentes.
1º - Evitar a condição IF e ELSE
2º - Usar polimorfismo melhorar a conectividade dos componentes
A solução de alguns problemas do polimorfismo tais como criar componentes de softwares conectáveis, é atribuir responsabilidade aos tipos para os quais o comportamento varia, usando operações polimórficos.
Framework – ao contrário da ferramenta ToolKit no framework o desenvolvedor terá que utilizar o roteiro do jeito que está definido na ferramenta, existem vários tipos de frameworks, alguns deles são:
Spring é um framework open source criado por Rod Johnson e descrito em seu livro "Expert One-on-One: J2EE Design e Development". Trata-se de um framework não intrusivo, baseado nos padrões de projeto inversão de controle (IoC) e injeção de dependência. Esse framework oferece diversos módulos que podem ser utilizados de acordo com as necessidades do projeto, como módulos voltados para desenvolvimento Web, persistência, acesso remoto e programação orientada a aspectos. Esse framework foi criado para que ele se conecte com outros frameworks, IoC (Inversão de Controle) não é a aplicação que controla, o controle ta fora da aplicação.
Bibliografia
Jacques Philippe Sauvé, http://walfredo.dsc.ufcg.edu.br/cursos/2002/progII20021/aulas/o_que_e_polimorfismo.htm>
<http://w3.ualg.pt/~hdaniel/poo/teorica/poot03.pdf> <http://imasters.uol.com.br/artigo/4497/spring_framework_introducao>
Contegix, Disponível em: <http://www.springframework.org/>
Aula 25 e 26 de Projetos Orientado a Objetos
Padrão MVC
Modelo-Vista-Controlador O MVC é uma estrutura padrão de software que pode ser usada para organizar o código de forma que a lógica de trabalho fique separada da apresentação dos dados.
Model
O Model é a parte do componente que encapsula os dados da aplicação. Na maioria das vezes vai fornecer rotinas para administrar e manipular dados. O model deve conter métodos para adicionar, eliminar e atualizar informações na base de dados. Também deve conter métodos para obter a lista existente. De modo geral, a técnica de acesso aos dados deve ser encapsulada no model. Desta forma, se uma aplicação for transferida de um sistema que usa banco de dados para um sistema que usa arquivos texto para guardar as informações, o único elemento que precisa ser alterado será o model - a View e o Controller não precisam ser modificados.
Notificar a View quando seofrer alteração (Padrão Observer);
Armazenar o estado da aplicação;
Armazenar as Regras de Negócio;
View
A view é a parte do componente usada para transformar e preparar os dados do model para que possam ser apresentados de alguma forma, geralmente o controller retira os dados do model e os entrega para a view. Esta, por sua vez, alimenta templates com estes dados para que possam ser apresentados ao usuário. A view não modifica os dados de nenhuma forma, apenas os apresenta.
Enviar os dados para Frame;
Receber os dados e as ações do usuário/Frame;
Ao ser notificada pelo Model, solicitar so Controller a atualização dos dados;
Controller O controller é responsável pelas respostas às ações dos usuários. No caso de uma aplicação web, uma ação de usuário (geralmente) é a solicitação de uma página. O controller vai determinar qual solicitação foi feita e vai responder de acordo, fazendo com que o model manipule os dados necessários para depois passá-los para a view para que possam ser mostrados. Considere o controller como o jogador de meio de campo.
Tratar os eventos da View;
Selecionar o que mostrar na View;
Bibliografia
Model-View-Controller (MVC)
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm>
MVC <http://pt.wikipedia.org/wiki/MVC>
Padrões de Projeto : O modelo MVC - Model View Controller <http://www.macoratti.net/vbn_mvc.htm>
Modelo-Vista-Controlador O MVC é uma estrutura padrão de software que pode ser usada para organizar o código de forma que a lógica de trabalho fique separada da apresentação dos dados.
Model
O Model é a parte do componente que encapsula os dados da aplicação. Na maioria das vezes vai fornecer rotinas para administrar e manipular dados. O model deve conter métodos para adicionar, eliminar e atualizar informações na base de dados. Também deve conter métodos para obter a lista existente. De modo geral, a técnica de acesso aos dados deve ser encapsulada no model. Desta forma, se uma aplicação for transferida de um sistema que usa banco de dados para um sistema que usa arquivos texto para guardar as informações, o único elemento que precisa ser alterado será o model - a View e o Controller não precisam ser modificados.
Notificar a View quando seofrer alteração (Padrão Observer);
Armazenar o estado da aplicação;
Armazenar as Regras de Negócio;
View
A view é a parte do componente usada para transformar e preparar os dados do model para que possam ser apresentados de alguma forma, geralmente o controller retira os dados do model e os entrega para a view. Esta, por sua vez, alimenta templates com estes dados para que possam ser apresentados ao usuário. A view não modifica os dados de nenhuma forma, apenas os apresenta.
Enviar os dados para Frame;
Receber os dados e as ações do usuário/Frame;
Ao ser notificada pelo Model, solicitar so Controller a atualização dos dados;
Controller O controller é responsável pelas respostas às ações dos usuários. No caso de uma aplicação web, uma ação de usuário (geralmente) é a solicitação de uma página. O controller vai determinar qual solicitação foi feita e vai responder de acordo, fazendo com que o model manipule os dados necessários para depois passá-los para a view para que possam ser mostrados. Considere o controller como o jogador de meio de campo.
Tratar os eventos da View;
Selecionar o que mostrar na View;
Bibliografia
Model-View-Controller (MVC)
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm>
MVC <http://pt.wikipedia.org/wiki/MVC>
Padrões de Projeto : O modelo MVC - Model View Controller <http://www.macoratti.net/vbn_mvc.htm>
quarta-feira, 14 de maio de 2008
Aula 23 e 24 de Projetos Orientado a Objetos
Padrão Command
O padrão Command é baseado em: encapsular uma solicitação como uma objeto, assim permitindo filas, rollbacks e façam logs. Conhecido também como Action ou Transaction.
O uso deste padrão muitas vezes é utilizado para substituir procedures no banco de dados, ou seja, caso o programador quiser que seu software execute um calculo ou então faça uma inserção em varias tabelas de seu banco de dados através de uma única solicitação, ele pode fazer com que seja realizado isso no próprio banco, ou seja, que o banco processe esta informação ou ele pode utilizar a camada de aplicação utilizando uma transaction, pois a mesma permite rollbacks e commit, assim mantendo a segurança de se houver falha em uma parte da inserção ou do calculo, não executara esta solicitação por inteiro.
Bibliografia: Material fornecido pelo professor e conhecimentos próprios.
O padrão Command é baseado em: encapsular uma solicitação como uma objeto, assim permitindo filas, rollbacks e façam logs. Conhecido também como Action ou Transaction.
O uso deste padrão muitas vezes é utilizado para substituir procedures no banco de dados, ou seja, caso o programador quiser que seu software execute um calculo ou então faça uma inserção em varias tabelas de seu banco de dados através de uma única solicitação, ele pode fazer com que seja realizado isso no próprio banco, ou seja, que o banco processe esta informação ou ele pode utilizar a camada de aplicação utilizando uma transaction, pois a mesma permite rollbacks e commit, assim mantendo a segurança de se houver falha em uma parte da inserção ou do calculo, não executara esta solicitação por inteiro.
Bibliografia: Material fornecido pelo professor e conhecimentos próprios.
sexta-feira, 9 de maio de 2008
Aula 21 e 22 de Projetos Orientado a Objetos
Padrão Observer
Este padrão tem como objetivo definir uma dependência de um para muitos entre objetos, para que quando um objeto mudar seu estado, seus dependentes atualizem automaticamente.
Este padrão disponibiliza uma facilidade maior de manutenção, pois a cada alteração de um objeto, não é necessária a atualização de todos os seu objetos dependentes, ou seja, não sendo necessário se preocupar com outros objetos, pois automaticamente eles iram reconhecer a atualização.
- Vantagens:
– Tanto observadores quando sujeitos observados
podem ser reutilizados e ter sua interface e
implementação alteradas sem afetar o sistema
– O acoplamento forte implicado pelo relacionamento
bidirecional é reduzido com o uso de interfaces e
classes abstratas
- Desvantagens:
– O abuso pode causar sério impacto na performance.
– Sistemas onde todos notificam todos a cada
mudança ficam inundados de requisições
("tempestade de eventos")
Bibliografia: Material fornecido pelo professor
Este padrão tem como objetivo definir uma dependência de um para muitos entre objetos, para que quando um objeto mudar seu estado, seus dependentes atualizem automaticamente.
Este padrão disponibiliza uma facilidade maior de manutenção, pois a cada alteração de um objeto, não é necessária a atualização de todos os seu objetos dependentes, ou seja, não sendo necessário se preocupar com outros objetos, pois automaticamente eles iram reconhecer a atualização.
- Vantagens:
– Tanto observadores quando sujeitos observados
podem ser reutilizados e ter sua interface e
implementação alteradas sem afetar o sistema
– O acoplamento forte implicado pelo relacionamento
bidirecional é reduzido com o uso de interfaces e
classes abstratas
- Desvantagens:
– O abuso pode causar sério impacto na performance.
– Sistemas onde todos notificam todos a cada
mudança ficam inundados de requisições
("tempestade de eventos")
Bibliografia: Material fornecido pelo professor
Aula 19 e 20 de Projetos Orientado a Objetos
Padrão Singleton
O padrão Singleton, ou seja, o padrão de responsabilidade foge à regra comum de que as responsabilidades devem ser distribuídas ao Máximo. Este padrão centraliza a responsabilidade em uma única instância de uma classe, assim garantindo que uma classe terá apenas uma única instância e garantindo um acesso global a ela. Este padrão garante que apenas um objeto exista independente do número de requisições que ele irá sofrer.
A utilização de Singleton tem que ser bem analisada, pois existem alguns pontos fortes porem alguns pontos fracos também.
Pontos Fortes:
- Acesso central e extensível a recursos e objetos
– Pode ter subclasses* (o que seria impossível se fosse apenas
usada uma classe com métodos estáticos)
Pontos Fracos:
– Qualidade da implementação depende da linguagem
– Difícil de testar (simulações podem depender de instância extra)
– Uso (abuso) como substituto para variáveis globais
– Criação "preguiçosa" é complicada em ambiente multithreaded
– Difícil ou impossível de implementar em ambiente distribuído (é
preciso garantir que cópias serializadas refiram-se ao mesmo
objeto)
Bibliografia: Material fornecido pelo professor.
O padrão Singleton, ou seja, o padrão de responsabilidade foge à regra comum de que as responsabilidades devem ser distribuídas ao Máximo. Este padrão centraliza a responsabilidade em uma única instância de uma classe, assim garantindo que uma classe terá apenas uma única instância e garantindo um acesso global a ela. Este padrão garante que apenas um objeto exista independente do número de requisições que ele irá sofrer.
A utilização de Singleton tem que ser bem analisada, pois existem alguns pontos fortes porem alguns pontos fracos também.
Pontos Fortes:
- Acesso central e extensível a recursos e objetos
– Pode ter subclasses* (o que seria impossível se fosse apenas
usada uma classe com métodos estáticos)
Pontos Fracos:
– Qualidade da implementação depende da linguagem
– Difícil de testar (simulações podem depender de instância extra)
– Uso (abuso) como substituto para variáveis globais
– Criação "preguiçosa" é complicada em ambiente multithreaded
– Difícil ou impossível de implementar em ambiente distribuído (é
preciso garantir que cópias serializadas refiram-se ao mesmo
objeto)
Bibliografia: Material fornecido pelo professor.
Assinar:
Postagens (Atom)