Las nueve reglas de oro para un mejor diseño de software

Después de mi encuentro con el arte del Pragmating Programming, Extreme Programming y AGILE Development, creo conveniente explicar un poco las nueve reglas fundamentales para un mejor diseño del software que podéis encontrar en cualquier de los libros que hablen sobre este tema. Primero empezaré explicando un poco que es esto de la programación pragmática y de la programación extrema o ágil, ya que son términos que hay que llegar a conocer bien. El programador pragmático es aquel que sigue las reglas básicas de la programación extrema, y los aplica a la ingeniería del software para desarrollar aplicaciones con una buena implementación en Orientación a Objetos, ya que hacer un buen uso de la OO es complicado.

¿Qué es Extreme Programming?

Extreme Programming es un enfoque ágil para el desarrollo de software que hace hincapié en la satisfacción del cliente y el trabajo en equipo. Además ofrece diseños limpios y software de alta calidad sobre un calendario realista.

Podemos encontrar buenas explicaciones en la wikipedia :
Extreme Programming y AGILE Development.

Las nueve reglas de oro:

1. Utilizar únicamente un nivel de indentación por método.
2. No utilizar la palabra clave "else".
3. Envolver todos los primitivos y cadenas.
4. Solo utilizar un punto en cada línea.
5. No abreviar.
6. Mantener todas las entidades pequeñas.
7. No utilizar clases con más de 2 variables de instáncia.
8. Uso de una sola clase en colecciones.
9. No usar Getter / Setter / propiedades.

1. Utilizar únicamente un nivel de indentación por método.

Cuando escribamos algún método, nunca tienen que haber más de un nivel de indentación por método, es decir si tenemos:

void Calcule() {
for (int i = 0, in= p.length(), i++) {
  Decrypt(p.charAt(i));
  for (int j = 0, in= p.length(), j++) {
     Remove(p.charAt(j));
  }
}
}

podemos ver que el nivel de indentación supera los 2 niveles, por lo tanto podemos ver que estamos haciendo algo mal, y que ya estamos haciendo demasiadas cosas en ese método, por lo tanto lo que hay que hacer es dividir los métodos.

void CalculeTotal() {
Calcule1();
Calcule2();
}

void Calcule1() {
for (int i = 0, in= p.length(), i++) {

          Decrypt(p.charAt(i));
     Calcule2(p);
     }
}

void Calcule2(String p) {

     for (int j = 0, in= p.length(), j++) {
     Remove(p.charAt(j));
}
}

2. No utilizar la palabra clave "else".

Todos los programadores entienden la clausula if / else, que es de las condiciones lógicas más simples que podemos tener en un lenguaje de programación, pero el hecho de usar esta sentencia provoca que podamos tener muchos anidamientos y que la lectura del código sea complicada.

Ejemplo:

double getPayAmount() {
    double result;
    if (_isDead) result = deadAmount();
    else {
        if (_isSeparated) result = separatedAmount();
        else {
            if (_isRetired) result = retiredAmount();
             else result = normalPayAmount();
        }
    }
  return result;
}

Solución:

double getPayAmount() {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();
    return normalPayAmount();
}

3. Envolver todos los primitivos y cadenas.

Ningún método debería tener un argumento que sea un tipo primitivo o un String. Por lo tanto, siempre que tengamos que pasar algún parámetro que sea primitivo, encapsularlo en un objeto, ya que es mucho más fácil identificar por ejemplo un argumento que sea tipo NIF y que sea un objeto que un NIF de tipo entero.

4. Solo utilizar un punto en cada línea.

Si queremos hacer esto:

buffer.append (letter.current.representation.substring(0, 1));

Podemos ver que hay más de un punto en una línea, y esto representa que estamos intentanto acceder a un parámetro de esa classe que está en un nivel muy profundo, y según el pragmatic programming aparece el siguiente texto:

"Puedes jugar con tus juguetes, con los juguetes que haces y con los juguetes que alguien te da. Pero nunca, nunca, nunca...juegues con los juguetes de los juguetes!."

Creo que esta interpretación queda bastante clara, por lo tanto deberiamos reducir esa representación a :

 StringBuffer buffer = new StringBuffer ();
 buffer.addTo(letter.text());

5. No abreviar.

Intenta que los métodos tengar como mínimo 1 o 2 palabras para describirlo, no abreviar los términos ni utilizar notación húngara.

6. Mantener todas las entidades pequeñas.

Una clase no puede tener más de 50 líneas, y un package no puede contener más de 10 clases.

7. No utilizar clases con más de 2 variables de instáncia.

Envez de hacer esto:

class Name {
  String first;
  String middle;
  String last;
}

Debemos hacer esto:

class Name {
  Surname family;
  GivenNames given;
}

class Surname {
  String family;
}

class GivenNames {
  List names;
}

8. Uso de una sola clase en colecciones.

Si una clase contiene una colección, entonces esta debe ser la única variable de instáncia en esa clase.

9. No usar Getter / Setter / propiedades.

Siempre hay que seguir la lógica de que los objetos siempre dicen, nunca preguntan. Por lo tanto los objetos no se menten en el funcionamiento interno de otros objetos, por lo tanto si el otro objeto tiene los datos, haz que este haga la operación, no otro.

Enlaces de interés:

http://books.pragprog.com/
http://sourcemaking.com/
http://www.diamond-sky.com/resources/xp/

Libros que hay que leer:

Pragmatic Programming

Agile Software Developement

Patterns of Enterprise Application Architecture