Pesquisar

sexta-feira, 22 de junho de 2007

Abstrair é preciso

Para que haja o entendimento global de um problema, devemos esquecer as especificidades. Ter uma visão macro é essêncial para um bom projeto. Logicamente o detalhamento também é importante, porém no momento certo senão pode atrapalhar o andamento.

Um problema clássico e do "analista-desenvolvedor", ele faz a analíse já pensando na linguagem, o que ocorre como o processo? Simplesmente trava.

Resolver grandes problemas requer todos os minímos detalhes, todavia para um inicio de solução é necessário ver bruscamente "como se estivesse num avião".

Imagine um programador solitário e um analista querendo entender, na sua totalidade, um S.O., como por exemplo um GNU/Linux. Com certeza iriam passar anos e mais anos e nada aconteceria.

terça-feira, 19 de junho de 2007

De quem é este método?




Um amigo lendo a apostila de Java e Orientação a Objetos da Caelum(r) - por sinal ótima apostila -, me questionou sobre como saber de quem é a responsabilidade de um método. (como atribuir e distribuir as responsabilidades entre as classes)

Mais especificamente, tem-se dois objetos Conta e Pessoa. Ele me disse:
- Mas quem saca dinheiro não é a pessoa?
- Porque que conta é que está com esse método?
- Não temos que "imitar" o mundo real?

Tentei explicar para que devemos chegar o mais perto do mundo real, não completamente igual ao mundo real. Sobre atribuir responsabilidades existem padrões (ou regras) e também vale o bom senso, existem padrões como o GRASP - Expert.

Padrão Expert
"Atribuir uma responsabilidade ao expert de informação - a classe que possui a informação necessária para preencher a responsabilidade"



Conta ou Pessoa preenchem a necessidade de sacar o dinheiro?
Quem é o expert da informação envolvida na responsabilidade, Conta ou Pessoa? (saldo,limite...)
Eu acredito que seja a Conta. O objeto Conta que conhece qual o limite, para não ultrapassar, e autualiza o saldo. Ou seja, a Conta é o Expert.

sexta-feira, 15 de junho de 2007

Relacionamentos em Diagramas de classes UML

Um relacionamento em UML nada mais é do que uma forma de expressar como um objeto poderá referenciar o outro.
Abaixo seguem dois diagramas de classes equivalentes.

A figura 1 e a 2 modelam o mesmo conceito uma Pessoa, porém a figura 1 é bem mais complexa de se entender do que a figura 2.
Note que cada relacionamento (agregação, composição...) pode ser criado com o uso de uma varivel de classe.

Porém quando se tem um problema um pouco mais complexo do que modelar um simples conceito como uma pessoa ai se tornar melhor o uso do estilo da primeira figura melhor.

Um modelo deve ser encarrado como algo que deve facilitar o entendimento, independe do diagrama, a figura deve ser clara para o entendimento do que se queria expressar.
Então quando for criar modelos não pense em apenas uma documentação mas sim um facilitador de problemas.

Favor não considerar essa modelagem como uma modelagem exemplo a ser comprida, tente entender apenas o conceito relacionamento entre classes.

Dicionário de sinônimos, siglas & afins

A área de TI troca constantemente o jeito de se expressar e "inventa" novas siglas a cada mês, o pior é que muitas dessas siglas já tem três, quatro ou mais sinônimos.
...
TDD= Desenvolvimento Guiado por Testes
DDD= Desenvolviemnto Guiado pelo Dominio
MDA = Arquitetura Guiado pelo Modelo
SOA=Arquitetura Orientada a Serviços
IoC==AOP==Injeção de Dependências é apenas uma forma de IoC, não são sinônimos
MVC=Model Vision Controller=Modelo Visão Controle
XP=eXtreme Programming=Uma metodologia ágil
DESIGN PATTERNS=Padrões de projeto
....

Isso sem descer para uma área especifíca como a plataforma Java, ai vem mais uma enxurrada: JCP, JSF, JDBC, JSP, JSR, EJB...

Devemos tomar cuidado para não cair no "geralzão" e perceber quando pessoas que dizem siglas ou palavras sem ao menos entenderem qual o significado.

Uma das palavras que acho mais interessante no mundo dos sistemas é componente,,, a definição de componente é ampla para entender que até mesmo um formulário pode ser um componente, e ao mesmo tempo tão restrita que é fica difícil entender o que é e o que não é um componente.

"Componente um agregado de software projetado para ser usado, sem modificação, por uma aplicação que está fora do controle dos criadores do componente. Por ' sem modificação ', eu quero dizer que a aplicação não altera o código-fonte dos componentes, apesar dela poder alterar o comportamento do componente extendendo-o de alguma maneira permitida pelos criadores do componentes." [Martin Fowler]

Com a ajuda de Philip Shoes, houve alguns ajustes.

quinta-feira, 14 de junho de 2007

Definir responsabilidades em orientação a objetos é tão importante quanto os relacionamentos.

Hoje , a pedido de um amigo, fui revisar (refatorar, manter,revisar...) códigos de uma "pequena parte" de um sistema de RH - bem básico feito dentro da própria empresa. Chegando lá fui informado que eu deveria olhar somente a "classe" chamada PessoaFisica.java, e que ele nela e somente nela que o problema estava. Me tranquilizaram, disseram que era para eu ficar calmo porque o sistema havia sido construído sobre OO e que tinha toda a "documentação".

Quando abri esta classe no Eclipse, tive uma tremenda surpressa, a classe tinha 6415 linhas de códigos. Assustado perguntei posso ver o "erro" acontecendo, bem descobri como consertar tal erro, porém aquela minha manutenção corretiva deveria ser feita em todas as partes da classe que tivessem um comportamente parecido, quer dizer consertei um problema e arrumei uns novos problemas.

Posso estar errado mas não tenho coragem de chamar aquilo de classe no máximo de um grande modulo de software, e nem aceitar tanta responsabilidade (mesmo que baseado somente no número de linhas de código) numa única classe. Aquele é um dos casos em que a Refatoração é mais (ou talvez) complicada do que um construção de uma classe nova.

sexta-feira, 1 de junho de 2007

Tudo bem, vou começar um projeto de software orientado a objetos

Pense no projeto em andamento, 'pule' a analise vá direto para a 'fase' de projeto.
Se está com dúvida sobre qual seria a modelagem melhor (ou mais correta) a ser feita em primeiro lugar...
Então, faça primeiro a modelagem das classes depois faça a modelagem de dados.
Outro tópico que pode ser interessante é o mapeamento entre o objeto e a tabela, relação que hoje está 'facilmente' resolvido com esses vários frameworks para mapeamento, jpa, NHibernate... mas isso é assunto para outro tópico.
Experimente isso - se nunca assim fez - !