Implementação não é nada. Design é tudo!
Quando estamos construindo um sistema OO, a base desse sistema é fundamental. Já é bíblica a frase " O Homem que construiu sua casa sobre a areia" . Para termos uma aplicação robusta, modular, escalável precisamos ter uma base muito bem fomentada, para isso o design é essencial. Pois como podemos construir artefatos que atendam essas premissas sobre uma base podre? A resposta é obvia, mas nem sempre o obvio é tão obvio. O Design de uma aplicação é mais importante do que qualquer tecnologia de implementação até mesmo a JEE. Não adianta usarmos Spring, Hibernate, MVC, etc se não temos:
A Divisão de papeis aumentara a coesão. Isso ira garantir que cada objeto não tem responsabilidades de mais, assim também cooperando com o baixo acoplamento. Sempre devemos utilizar estruturas como herança e interfaces, programar para interfaces é muito importante. Para facilitar o trabalho com interfaces podemos utilizar o Spring framework, por exemplo. O Spring e outros frameworks como Hibernate e XStream são muito bem desenhamos, podemos e devemos olhar como é o desgin desses frameworks e se possível reutilizar seus modelos.
O Ser humano precisa aprender com a história, com os erros dos outros, muitas vezes cometemos os mesmos erros que outras pessoas já cometeram, a foram de evitar isso é sempre pesquisar por frameworks no mercado e utiliza-los quando possível. No caso de nenhum atender(Acho difícil) devemos estender o mesmo, um bom exemplo é o Spring que é um framework extremamente extensível. Em sintese utilizando interfaces para separar o contrato da sua(s) implementação concerta(s). Devemos utilizar classes abstratas somente quando temos atributos em comum e um reutilizarão de métodos, se não a interface é melhor.
Vamos supor que eu tenho um objeto de domino(jogo) com 15 propriedades e eu utilizo esse objeto em 50 outros objetos do meu sistema, agora imagine se mais um artefato do sistema precisar acessar esse objeto de uma forma remota por exemplo(EJB ou integração com outro sistema) porem eu preciso de uma propriedade 5 propriedades novas e que não seram utilizadas nos outros 50 objetos, e agora??? Eu mudo o objeto de forma que eu adiciono as 5 propriedades novo? Se eu fizer isso eu vou estar perdendo em coesão pois os 50 objetos não usam essas 5 propriedades que só seram utilizadas em 1 objeto. Eu poderia criar um VO ou DTO para isso? Sim poderia mais eu estaria perdendo em termos de rastriabilidade pois não ia ter nenhum recurso computacional que me avisa se sobre essa dependência, por que o VO não tem referencia com o objeto original. Qual seria a melhor solução.
No inicio já poderia ter uma interface para esse objeto e uma implementação padrão ai nesse necessidade de adicionar mais 5 propriedades eu posso colocar isso em um objeto filho que estende o primeiro ou melhor ainda, criar outra interface e utilizar a interface nesse objeto filho.
Quando não pensamos no design o sistema fica preso e quando grande as mudanças são muito difíceis de se rastrear e começa a gambiarra. Começa com algo pequeno e quando você se da por si fica a frente de uma grande bola de merda. Cuidado! Use a cabeça, pense bem no design.
- Alta coesão
- Baixo acoplamento
- Utilizando Design Patterns
- Modelagem UML
- Divisão de papeis
- Utilizando Interfaces e Herança
- Re-utilizando design de frameworks bem escritos
- Não re-inventando a roda
A Divisão de papeis aumentara a coesão. Isso ira garantir que cada objeto não tem responsabilidades de mais, assim também cooperando com o baixo acoplamento. Sempre devemos utilizar estruturas como herança e interfaces, programar para interfaces é muito importante. Para facilitar o trabalho com interfaces podemos utilizar o Spring framework, por exemplo. O Spring e outros frameworks como Hibernate e XStream são muito bem desenhamos, podemos e devemos olhar como é o desgin desses frameworks e se possível reutilizar seus modelos.
O Ser humano precisa aprender com a história, com os erros dos outros, muitas vezes cometemos os mesmos erros que outras pessoas já cometeram, a foram de evitar isso é sempre pesquisar por frameworks no mercado e utiliza-los quando possível. No caso de nenhum atender(Acho difícil) devemos estender o mesmo, um bom exemplo é o Spring que é um framework extremamente extensível. Em sintese utilizando interfaces para separar o contrato da sua(s) implementação concerta(s). Devemos utilizar classes abstratas somente quando temos atributos em comum e um reutilizarão de métodos, se não a interface é melhor.
Vamos supor que eu tenho um objeto de domino(jogo) com 15 propriedades e eu utilizo esse objeto em 50 outros objetos do meu sistema, agora imagine se mais um artefato do sistema precisar acessar esse objeto de uma forma remota por exemplo(EJB ou integração com outro sistema) porem eu preciso de uma propriedade 5 propriedades novas e que não seram utilizadas nos outros 50 objetos, e agora??? Eu mudo o objeto de forma que eu adiciono as 5 propriedades novo? Se eu fizer isso eu vou estar perdendo em coesão pois os 50 objetos não usam essas 5 propriedades que só seram utilizadas em 1 objeto. Eu poderia criar um VO ou DTO para isso? Sim poderia mais eu estaria perdendo em termos de rastriabilidade pois não ia ter nenhum recurso computacional que me avisa se sobre essa dependência, por que o VO não tem referencia com o objeto original. Qual seria a melhor solução.
No inicio já poderia ter uma interface para esse objeto e uma implementação padrão ai nesse necessidade de adicionar mais 5 propriedades eu posso colocar isso em um objeto filho que estende o primeiro ou melhor ainda, criar outra interface e utilizar a interface nesse objeto filho.
Quando não pensamos no design o sistema fica preso e quando grande as mudanças são muito difíceis de se rastrear e começa a gambiarra. Começa com algo pequeno e quando você se da por si fica a frente de uma grande bola de merda. Cuidado! Use a cabeça, pense bem no design.
