Imagina a cena. Seu colega pede ajuda num trecho qualquer de código. Ele começa a te explicar o que está fazendo:
Então (ele é paulista), eu criei esse agrupamento de instruções parametrizáveis, que retorna um valor que é uma cópia de um objeto. Daí eu agrupei alguns destes numa unidade e coloquei algumas variáveis que eles compartilham. Como alguns destes agrupamentos não são utilizados por outros agrupamentos externos, defini uma política de exposição para eles…
Você entendeu? Dependendo do sue nível de imersão em cosias abstratas relacionadas á programação, talvez sim, mas o desenvolvedor mediano vai fazer “uhum” algumas vezes e olhar para o código para ver o que esse cidadão queria dizer. E ele vê o que ele tentou explicar:
public class Usuario{
private int idade;
private boolean sexo;
private double altura;
public void setIdade(int idadeNova){
if (idadeNova>13) {
idade= idadeNova;
calcularAltura();
}
else{
throw new IllegalArgumentException(”Idade baixa demais para usar o sistema” );
}
}
private calcularAltura(){
altura=idade*10.45;
}
}
Aí você pensa
Caramba, não seria mais fácil ele dizer que fez uma classe com métodos públicos e privados e atributos privados?
Seria, mas e se ele não conhecesse este termo? Sim, o exemplo é bem forçado, mas é de propósito.
Muita gente torce o nariz quando alguém mostra um Pattern. Logo pensam: “Quanta besteira…eu uso isso há anos!” e esquecem que tão importante quanto criar Patterns é catalogá-los. Pense em algum padrão que você use no dia a dia. Agora imagina que você tem uma dúvida com o uso deste.
Você vai num fórum qualquer, o GUJ por exemplo, e tenta descrever sua dúvida. Você pode gastar dois parágrafos explicando o que fez ou pode simplesmente dizer o nome do Padrão e a pessoa que ler já sabe do que se trata (ou pelo menos vai saber se procurar).
Existem livros e sites que fazem apenas isso. Eles documentam e catalogam padrões, colocam eles dentro de contextos, listam vantagens e desvantagens, mas não necessariamente criam nada novo. Você não vai encontrar novas geniais soluções, apenas soluções clássicas catalogadas.
Além do óbvio benefício de acabar conhecendo uma solução que já é clássica mas você não conhecia, outro benefício não tão óbvio está simplesmente em termos um idioma comum entre profissionais.
Se você falar para alguém de .Net ou C++ que fez um Observer, ele provavelmente sabe do que você está falando. Se falar que usa um DAO, apesar de ser algo mais comum em Java EE, é bem capaz de ser entendido (menos pelo cara do .Net que pode se confundir com esse negócio de DAO/ADO), como este padrão também tem outros nomes mais genéricos, pode ser que ele também use isso nas suas aplicações.
Um padrão não é padrão desde seu nascimento. Ele nasce como uma solução isolada, e de repente alguém pensa “Ei, eu posso resolver este problema do mesmo jeito que fiz naquele caso…” (por isso Ted Neward fala que o sistema só morre quando as máquinas são desligadas, o código fonte é apagado e o último desenvolvedor é morto). E por mais que você use e reuse, ensine esta técnica ela só vai virar um padrão no dia em que for catalogada. Seja em um livro, paper ou site ou qualquer coisa.
Se alguém te disser que recebeu um buquê de as flores que pertencem à família rosasceae, que são arbustos ou trepadeiras, providos de acúleos com folhas simples partidas em 5 ou 7 lóbulos de bordos denteados, com 5 pétalas, muitos estamos e um ovário ínfero… estão continuam sendo rosas, mas não seria mais fácil se vocês falassem a mesma língua?
