Há certas regras universais e principios no desenvolvimento de software que guia os engenheiros que trabalham na àrea. Nesta pagina tentamos decompor estes prinicipio enumerandoos e explicando cada um em suma.

KISS

(Keep it Simple Stupid) ou (Keep it Short and Simple)

Porquê?

• Menos codigo significa menos tempo a escreve-lo, tem menos bugs e é de mais facil manutenção.
• Pode se dizer que no código e levando este principio à risca podemos dizer que o codigo esta completo não quando não falta adicionar nada mas sim quando já não dá para tirar nada.

• Kiss - Wikipedia

YAGNI

(You ain't gonna need it)

Porquê?

• Não adianta perder tempo numa coisa que só irá ser implementada numa futura versão.
• Torna o codigo confuso e "gordo" para uma função do softaware que ainda não foi implementada e que, provavelmente com alguma mudança de planos, não irá ser implementado da forma que hoje se pensa que vai, tornando-se inutil o esforço.

• Sempre tenta implementar apenas o que é preciso sem fazer futurologia, ou seja, implementar coisas que no futuro irá ser implentado.

• YAGNI

Separação de Responsabilidade

Porquê?

• Simplifica o desenho e manutenção do sistema.
• Quando bem desenhado permite que as secções independentes sejam atualizadas e expandidas sem ter que fazer alterações a outras partes do projecto.
• Evita que ao atualizar codigo, por exemplo, na ligação à base de dados façamos com que outra parte distinta como uma regra de negocio deixe de funcionar.

• Como? *

• Programar e dividir sempre o programa em modulos cada um com a sua função bem definida.

DRY

Não te repitas! (Don't repeat yourself)

Porquê?

• Imagine um programa em que numa secção deixa os utilizadores registarem-se e inserir os seus dados na BD. Se mais tarde você fizer uma aplicação para esse mesmo programa e tiver que fazer novamente o codigo para o utilizador se registar na base de dados esta-se a repetir e isto pode levar a muitos bugs e um pesadelo para descobrir o que se passa no codigo porque toda a gente espera que a inserção de novos utilizadores seja feito apenas por um modulo. Além disso cada vez que você tiver que alterar o codigo em que o utilizador é inserido irá ter que o alterar em N lugares onde o criou.

• Seguindo os principio acima é facil conseguir isto, basta não se repetir. No problema acima basta criar um modulo que recebe a info dos utilizadores e insere na base de dados, quando e se for preciso, ser alterado, apenas este modulo é alterado e subsituido não precisa de procurar onde há código que o faz.
• Identificar cada uma da responsabilidade de cada modulo do software e criar os modulos reusaveis e com nomes bem explicitos da sua função no sistema para que mais tarde seja facil os encontrar, reusar ou atualizar.

Crie codigo para quem o vai manter.

Evite otimizações prematuras.

Porquê?

• Antes de ter o software desenhado como você tem a certeza de onde ele é limitado ou lento?
• Codigo otimizado é normalmente mais dificil de ler e manter.

• Apenas se preocupe com a velocidade quando estiver definido onde o seu programa esta lento e porquê.

Minimize o emparelhamento

Considere a seguinte função:

public void insertStatsForTheDay(Db connection){
Stats stats = StatsGenerator.getStats();
connection.insert(stats);
**connection.close();**
}

Na função acima é obvio que ela faz uma coisa a mais que é fechar a conexão com a BD a responsabilidade dela era apenas inserir as estatiticas ninguem espera que depois de usar esta função terá que reabrir a conexão com a base de dados. Quem mais tarde vier a mexer neste codigo no meio de muitos ficheiros de codigos boa sorte a descobrir porque a conexão às vezes se encontra fechada sem razão aparente.

Lei de Deméter

Principio do menor conhecimento possível

No exemplo do método insertStatsForTheDay(Db connection); só é possivel aquele objecto fechar a conexão porque lhe é passado um objecto da Base de Dados. Se tivesse sido criado um interface ou o metodo de close connection tivesse protegido o bug poderia ocorrer na mesma mais iria ser muito mais facil de detectar.

Recursos:

• Lei de Demeter na Wikipédia

Liskov Substitution Principle

Interface Segregation Principle

Segregação de interfaces

Considere o seguinte mau exemplo:

public abstact class Passaro{
public abstract void comer();
public abstract void voar();
}

public class Pinguim extends Ave {
@Override
public void comer(){
System.out.println("Este pinguim esta a comer");
}
@Override
public void voar(){
throw new RuntimeException("Os pinguins não voam! :(");
}
}

Apesar de muitas aves voarem nem todas o fazem criar o metodo public abstract void voar() na classe mãe é estar a pedir problemas que irão aparecer mais tarde. Para contornarmos o problema o melhor que fazemos é criar um interface que será implementado pelas aves que voam, no nosso caso o pinguim não o implementará mas um papagaio, poderá faze-lo.

Deste modo fariamos o nosso programa teria o seguinte:

public abstact class Passaro{
public abstract void voar();
}
public interface Voa{
public void voar();
}
public class Pinguim extends Ave {
@Override
public void comer(){
System.out.println("Este pinguim esta a comer");
}
}
public class Papagaio extends Ave implements Voa {
@Override
public void comer(){
System.out.println("Este papagaio está a comer");
}
@Override
public void voar(){
System.out.println("Este papagaio está a voar");
}
}

Deste modo apenas as aves que voam implementariam o interface "Voa" e não teriamos que andar sempre a evitar aquele metodo que não serve a todas as implementações de Ave.

Conclusão