Spring

Blog referente a aula do dia 19/06/2008

Spring

Spring é um framework open source baseado nos princípios de inversão de controle e injeção de dependência já falados aqui neste blog.

No Spring é o "container" que instancia as classes da aplicação JAVA, definindo as dependências entre elas através da configuração de um arquivo XML permitindo assim um baixo acoplamento entre as classes.

Possuidor de uma arquitetura baseada em interfaces , o Spring surge como uma boa alternativa ao complexo uso dos EJB's.

Esse Spring é danado mesmo !!!

Boa semana a todos

Boa sorte na prova

Bibliografia:
http://pt.wikipedia.org/wiki/Spring_Framework

XP - Extreme Programing

Blog referente a aula de 10/6/2008

XP - Extreme Programing

Extreme Programing

É uma metodologia de programação ágil para equipes pequenas que trabalharam no desenvolvimento de softwares com poucos requisitos e com muitas mudanças durante a sua implementação

Geralmente formado por grupos de 12 pessoas.

Surgiu nos anos 80 através do Small Talk, é vc programar de modo eficiente , seguindo alguns critérios de comportamento , tais como:

Programação em Par – ou seja , um programa e o outro acompanha o código dando sugestões ao parceiro sobre algum erro.

O XP se baseia em 4 valores fundamentais:

Feedback:

Nele o cliente reaprende com o sistema e o reavalia, ou seja vc pega programa mostra ao cliente e ele lhe dá o sinal positivo de retorno , se ficou bom ou não.

Comunicação:

Como a equipe é pequena , a comunicação é total e bem vinda, rende muito mais na produção.

Simplicidade

Nada de invenções ou previsões, ou seja implemente apenas o necessário.

Coragem

Ousadia , alterar algo que já esta certo procurando uma maior melhora, correr o risco de estragar algo que já esta funcionando muito bem.

O XP se destina a grupos de programadores pequenos, projetos rápidos , e linhas de código bem volumosas , de 1000 a 250.000 linhas.

Os princípios do XP são comunicação total com o cliente visando o feedback , simplicidade total no programa, nele valoriza-se muito pessoas que sejam aptas e que queiram mudanças , ou seja não tenham medo de mudar e aceitem desafios.

Nele a alta qualidade no desenvolvimento é essencial.

Práticas do XP

Jogo do Planejamento

Planejamento é essencial entre os programadores
Fases Pequenas
O desenvolvimento é feito em iterações semanais , onde desenvolvedores e clientes interagem entre si para o bom desenvolvimento, sendo que o cliente tem papel fundamental , pois ele fica sabendo o que esta acontecendo e o que virá a acontecer no projeto.

Metáfora

Baseia-se em exemplos, em situações , usando-as metaforicamente na solução do dia a dia.
É preciso traduzir as palavras do cliente para o significado que ele espera dentro do projeto.

Projeto Simples

Simplicidade é o princípio fundamental do XP, se o cliente o mandar fazer uma aplicação de login com senha 123 , faça apenas o que ele pediu , não se preocupe com restrições , programação fácil deve ser substituída por código simples.

Testes

Primeiro crie os testes unitários , depois crie o código para que os testes funcionem. Esta abordagem é complexa no início, pois vai contra o processo de desenvolvimento de muitos anos. Só que os testes unitários são essenciais para que a qualidade do projeto seja mantida.

Refatoração

Aproveitar código já existente , atualizando-o visando a sua melhora, processo que permite a melhoria continua da programação, melhora a clareza do código.

Exemplos de refatoração:

- Mudanças de nome de variáveis , classes e etc.
- Pequenas mudanças na arquitetura.

Programação em par

Dois programadores juntos , um digitando e o outro acompanhando o código digitado, geralmente coloca-se um programador inexperiente com um já experiente , onde o menos “maduro” fica no computador digitando o código e o instrutor fica ao seu lado auxiliando-o no seu desenvolvimento , este trabalho coletivo beneficia o trabalho proporcionando um código fonte de melhor qualidade.

Exemplo de programação em par
EX:Sistema de multimídia orientado a objetos.



Propriedade Coletiva

Ninguém é dono do código , propriedade coletiva, tanto que qualquer desenvolvedor da equipe pode mudar e melhorar o código do outro.

Integração Contínua

Sempre que produzir uma funcionalidade , nunca demore muito tempo para integrá-la a versão atual do sistema , procure sempre que terminar sua aplicação integrá-la em tempo real.

Semana de 40 horas

Trabalhar com qualidade , sem horas extras, horas extras são permitidas somente quando trouxerem produtividade a execução do projeto, não existe essa de levar serviço para casa , trabalhe bem e produza bem no seu horário de serviço.

Cliente junto aos desenvolvedores

O cliente participa de todo o processo de execução do sistema , podendo até opinar.
Padronização do código

Código padronizado

Deve se seguir certas normas, pois assim um código digitado por vários desenvolvedores fica integrado , como se fosse feito por um só , sem confusões.

Pequenos releases

Liberação de pequenas versões funcionais do projeto auxilia muito no processo de aceitação por parte do cliente

O código

Padrões de implementação adotados por todo o grupo, tem que ser o mais claro possível e entendido por todos os desenvolvedores.

Até a próxima

Bibliografia:

WIKIPEDIA: http://pt.wikipedia.org/wiki/Programação_extrema

Variações Protegidas

Blog referente a aula do dia 09/06/2008

Variação Protegida

Solução das variações

Problema

Como que se consegue projetos de maneira que , o que você tenha implementado nesses elementos não prejudiquem a '"boa" execução dos outros?

Uma boa solução seria identificar os pontos de variação, atribuir responsabilidades a estes pontos criando uma interface que atue estavelmente entre eles.

1. O princípio básico da VP é manter a flexibilidade e proteção nas aplicações dos sistemas. Ela atua contra essas variações.
   
   Posso dizer como desenvolvedor “verde” ainda que para se obter uma boa VP no começo segue-se alguns princípios como encapsular dados, interfaces e um bom uso do polimorfismo, só que com o tempo e amadurecimento , se aprendem novos mecanismos para proteção contra variações:
   
   Segue abaixo alguns mecanismos de VP
   
   Projetos dirigidos por dados (data-driven designs)
   
   Este projetos englobam técnicas de inserção em código , leitura de valores , inspeção de caminhos de classe , eles são usados para mudar o comportamento do sistema ou talvez impondo padrões em tempo de execução. Ex – XML e WEB-XML.
   
   Pesquisa de Serviço: Ex:(SOA) – Analise Orientada a Serviços
   
   Inclui técnicas como o uso de serviços de atribuição de nomes, um bom exemplo disso é o SOA (Analise Orientada a Serviços).
   
   Proporciona ao cliente uma proteção contras as variações que possam ocorrer na localização dos serviços.
   
   Projetos dirigidos por interpretador:
   
   Um bom exemplo é a JVM, são projetos baseados em regras de uma fonte externa, ou seja é uma máquina virtual onde coloca-se regras dentro dela e ela toma decisões em cima daquelas regras.
   
   Projetos reflexivos:
   
   Ao meu entender funciona da seguinte maneira, funciona como uma substituição de métodos, ou seja , o fato de se apagar um método de uma aplicação não trava o sistema, pois ele é substituído por um método existente.
   
   Acesso Uniforme:
   
   Existente somente em algumas linguagens.
   
   Como posso explicar isso !!!, bom ao meu entender ele valida as denominações dos tipos no código de qualquer maneira , ou seja , vejamos o exemplo abaixo para uma melhor explicação.
   
   Ex: avião.decolar;
   
   “Decolar” no caso acima é aceito de duas formas , tanto como método quanto atributo e é aí que entra o entendimento do acesso uniforme, ele aceita as duas formas.
   
   O C# é um bom exemplo de acesso uniforme , pois ele aceita essa forma de definição.
   
   Princípio da substituição de LISKOV
   
   Introduzido por Bárbara Liskov é resumida da seguinte forma:
   
   Se q(x) é uma propriedade demonstrável dos objetos x de tipo T. Então q(y) deve ser verdadeiro para objetos y de tipo S onde S é um subtipo de T.
   
   Essa visão de subtipo é baseada na noção de substituição, ou seja , se B é um subtipo de A, então os objetos do tipo A, em um programa, podem ser substituídos pelos objetos de tipo B sem que seja necessário alterar as propriedades deste programa.

Uma ótima semana a todos e boa sorte na prova de segunda !!!!!

Bibliografia

Livro: UTILIZANDO UML E PADRÕES - Craig Larman

http://pt.wikipedia.org/wiki/Princípio_da_substituição_de_Liskov

Indireção

Blog referente a aula do dia 02/06/2008

Bom dia caros visitantes, hoje falarei sobre um padrão muito interessante , interessante pelo fato de que ele facilita e muuuuiiiiiiitooooo a vida de um desenvolvedor, projetista,analista e etc...

No episódio de hoje !!!

Indireção

O problema surge justamente em saber a qual objeto atribuir a responsabilidade de ser o mediador evitando a ocorrência de acoplamento direto entre os objetos.

Uma boa e inteligente solução para este tipo de problema seria a criação de um mediador, ou seja , cria-se um objeto intermediário para controlar outros componentes causando uma indireção entre eles.

Em outras palavras , o padrão Indireção atribui responsabilidade a um objeto intermediário para ser o mediador entre outros componentes, evitando assim que eles sejam diretamente acoplados.
Um bom exemplo disso seria como na Invenção Pura, a utilização do Armazenamento Persistente que atua como um intermediário entre a venda e o banco de dados.

Uma das maiores motivações para a indireção é o acoplamento fraco, onde um intermediário é usado para desacoplar os componentes.

A Indireção serviu como padrão modelo para muitos outros padrões, o adapter é um deles , até Invenções Puras são criadas através do padrão indireção.

Uma de suas vantagens é o fraco acoplamento entre suas classes.

Boa semana a todos !!!

Bibliografia:

http:// groups.msn.com/cafedotnet/grasppadresssoftware.msnw

Livro - UTILIZANDO UML E PADRÕES - Craig Larman

Invenção Pura !!!!!

Blog referente a aula do dia 26/05/2008

Solução

Consiste em inventar uma classe que suporte a coesão alta , acoplamento fraco e a reutilização, é uma classe fruto da imaginação, inventada de momento, o que acaba por tornar o projeto muito puro.

O problema se origina de maneira ao se atribuir responsabilidades apenas as classes de domínio, acaba por ocasionar problemas com coesão e acoplamento, ou pior tornam a classe impossível de ser reutilizada.

Veja um exemplo:

Pelo que entendi , a classe venda de acordo com o padrão especialista seria o responsável por salvar as suas próprias instancias em um banco de dados, só que é importante salientar que:

Seriam necessárias dúvidas operações de suporte relacionadas a banco de dados, nenhuma delas relacionadas a venda , o que tornaria a classe "Venda" não coesa.

Além disso a classe venda precisa ser acoplada ao banco de dados relacional aumentando assim o seu acoplamento.

Sendo assim , mesmo que o padrão especialista concorde que venda é a classe essencial para salvar a si mesma em um BD, ela leva todos os problemas que pedem que seja inventado algo e é aí que entra a invenção pura.

Uma solução seria criar uma classe exclusiva, exclusiva no sentido de ser utilizada somente para salvar os dados em um banco de dados relacional através de armazenamento persistente.

Peraí , mas o que vêm a ser "Armazenamento Persistente"??

Nada mais é do que algo criado por conveniência para auxiliar o desenvolvedor.

Segues abaixo alguns dos problemas resolvidos por invenção pura:

- A classe fica bem projetada com alta coesão e acoplamento fraco.

A classe armazenamento persistente por ser usada como auxilio ao desenvolvedor torna-se apta as ser utilizada várias vezes.

Por hoje é só pe-pe-pessoal, hehehe

Até semana que vêm.

BIBLIOGRAFIA:

http://groups.msn.com/cafedotnet/graspadress

UTILIZANDO UML E PADRÕES - Craig Larman

Inversão de Controle e Injeção de Dependência - 26-05-2008

Referente a aula 25 do dia 26/05/2008

Vamos aprender mais ???

heheheheh

Hoje nós iremos aprender um pouco sobre dois assuntos muito importantes !!!

Inversão de Controle e Injeção de Dependência

Inversão de controle – Também chamado de princípio de hollywood, ou seja “não nos chame , nós chamamos vc” . Um exemplo disso é o Template Method.

É uma forma de controlar e desenvolver aplicações de forma a deixa-las mais simples e mais limpas . Digamos que ele seja usado para dar uma certa “elegância” ao código.

Injeção de dependência – É uma técnica utilizada pra instanciar classes concretas, se fazer um acoplamento entre elas. Projetos que usam este tipo de injeção beneficiam muitos containeres de injeção de dependência.
É um padrão utilizado quando é necessário manter o baixo nível de acoplamento entre os módulos do sistema.
Neste tipo de Padrão as dependências entre os módulos não são definidas pelo programador e sim pelo container, este sim é responsável por injetar os componentes. Este padrão se relaciona com o padrão inversão de controle , mas isso não quer dizer que os dois tenham propósitos idênticos ou sejam a mesma coisa.

Olha , gostei muito desse assunto , espero que os próximos assuntos não sejam tão chatos e complexos como os anteriores.

heheheh

Ta pensando o quê !!!!, pensa que ser um bom desenvolvedor é fácil !!!!

Rala meu filho !!!!, rala !!!

heheheheh

Até o próximo blog !!!

BIBLIOGRAFIA:

http://pt.wikipedia.org/wiki/Inversão_de_controle