A velocidade e necessidade de aprendizado a novas tecnologias que vem surgindo no mercado atual, causa uma grande euforia na maioria dos desenvolvedores atuais. O que faz com que sejamos levados a fazer as coisas ao velho modo “nas coxas“.
Uma forma simples de se pensar no Desing de sua aplicação, é aplicar o velho termo É UM e TEM UM. A coisa é simples, porém trás grandes lucros. Vejamos:
É UM
Parte da herança de classes ou implementação de interfaces.
Esse termo, é o mesmo que dizer “A Ferrari é um tipo de Carro” ou “O Carro é um tipo de Veículo”, assim como “Uma moto É UM tipo de Veículo”.
Mas o que isso tem haver?
Digamos que você precisa desenhar um sistema OO para controlar o campeonato brasileiro. A primeira coisa que vem a mente ao falar de fultebol, são os times. Assim:
class Time {
static final NUMBER_OF_PLAYERS_PLAYING = 11;
void comemorarVitoria() {
System.out.println("IIIIIIIUUHHHHHHUUUUUUUUUUUU!!!!!!")
};
}
Agora temos um time que tem um número máximo de 11 jogares em campo e sabe comemorar uma vitória. Especializando um pouco mais nossas classes, podemos agora saber quem são os times que vão jogar.
class Palmeiras extends Time {
}
Assim sendo, temos então a relação que gostaríamos, “O Palmeiras É UM Time”.
Ao se estruturar a aplicação, deve-se pensar nas partes que É UM de alguém e modelalos como tal. Fica fácil imaginar essa dependência pensando se ele É UM do objeto que você quer. Vejamos alguns exemplos:
“Gol É UM Carro” (Mesmo que a Wolks diga que não)
“Cliente É UMA Pessoa”
“Coca_Cola É UM Refrigerante”
“Tomate É UMA Fruta” (Para não se confundir)
e assim segue…
Todas essas associações, são feitas através da herança que existe entre os objetos.
Certo, entendi porque É UM, mas e quando é que ele tem um?
TEM UM
Um objeto TEM UM, quando ele utiliza o outro objeto. Ou seja, ocorre quando o objeto que TEM UM, possui uma referência a uma instância de outro objeto.
Continuando o Desing de nosso sitema do Campeonato Brasileiro, vejamos então, o Palmeira É UM Time, mas ele também TEM UM Técnico.
class Tecnico {
String nome;
Date inicioDaCarreira;
int numeroDeCampeonatosGanhos;
// get's e set's
}
class Palmeiras extends Time {
Tecnico tecnico;
}
O código acima demostra bem, o relacionamento TEM UM. O Palmeiras TEM UM Tecnico. O código acima ainda poderia ser melhorado, colocando-se o Tecnico na superclasse Time, pois todo Time TEM UM Tecnico. Porém, apenas para fins didáticos, foi que fiz como está.
Um mal design seria fazer algo parecido com isso:
class Tecnico extends Time {
String nome;
Date inicioDaCarreira;
int numeroDeCampeonatosGanhos;
// get's e set's
}
class Palmeiras extends Tecnico {
}
No final das contas o Palmeiras ainda É UM Time, porém o Tecnico NÃO É UM Time, por isso ele não deve extender de Time, e muito menos o Palmeiras NÃO É UM Tecnico, ele também não deve extender de Tecnico.
Você pode estar imaginando, “Quem seria louco o bastante para fazer algo parecido com isso?”. Infelizmente, como dito acima, muitos programadores hoje, que aprendem programação “por demanda”, acabam cometendo erros primordiais simplesmente por não conhecerem as formas de design simples de aplicações OO. Ou ainda programadores que veem de outras linguagens estruturais, e tem dificuldade de pensar em sistemas verdadeiramente OO.
É UM e TEM UM são velhos conhecidos dos Desings de Sistemas OO, e fazem uma diferença imensa no momento de pensar a estrutura da aplicação.