Object Calisthenics
Seguramente conozcas los principios SOLID pero ¿Qué es Object Calisthenics? Pues se trata de otra colección de nueve principios a aplicar en el desarollo de la programación orientada a objetos. Menos conocidos que los principios SOLID, pero igual de interesantes.
De esto.
No hagas esto:
No hagas esto:
1. Usa un sólo nivel de indentación por método.
Hace que tengas un código más legible y te da la oportunidad de reutilizar código.De esto.
class Board {
String board() {
StringBuffer buf = new StringBuffer();
for (int i = 0; i < 10; i++) {
for (int j = 0; j < 10; j++) {
buf.append(data[i][j]);
}
buf.append("\n");
}
return buf.toString();
}
}
A esto:
class Board {
String board() {
StringBuffer buf = new StringBuffer();
collectRows(buf);
return buf.toString();
}
void collectRows(StringBuffer buf) {
for (int i = 0; i < 10; i++) {
collectRow(buf, i)
}
}
void collectRow(StringBuffer buf, int row) {
for (int i = 0; i < 10; i++) {
buf.append(data[row][i]);
}
buf.append("\n");
}
}
2. No uses ELSE.
Cuando un condicional termina la ejecución de un método, no tiene sentido indentar el siguiente codigo, hace el código menos legible, y cada vez menos si después añadimos otros condicionales.No hagas esto:
if (status == DONE) {
doSomething();
} else {
doSomethingElse();
}
Sino esto:
if (status == DONE) {
return doSomething();
}
return doSomethingElse();
3. Envuelve los primitivos y las cadenas.
Si la variable de tu tipo primitivo (int, short, float, etc.) o tu cadena tiene comportamiento entonces debes encapsularlo. Variables muy facilmente reconocibles: Dinero, Horas, Matrícula o Codigo postal serían buenos ejemplos.public class Month
{
private int month;
public Month(int month)
{
if (month < 1 || month > 12)
{
throw new IllegalArgumentException("Month cannot be less than 1 or greater then 12");
}
this.month = month;
}
}
4. Usar un solo . o -> por línea. Ley de Demeter.
A veces es difícil saber que objeto debería tener ciertas responsabilidades. Si ves líneas de código con muchos puntos . o invocaciones -> es posible que esten en el lugar equivocado. Intenta solucionarlo, si no sigue la Ley de Demeter o “Habla solo con tus amigos", trata de preguntar a tu clase que haga algo por ti.No hagas esto:
a.getFoo().getBar().getBaaz().doSomething();
Sino esto:
a.foo(b.foo());
5. No abrevies.
Abreviar no tiene sentido y puede resultar confuso. Este punto no tiene más misterio.6. Manten las clases pequeñas.
Ninguna clase debería contener más de 50 líneas de código como regla general, y los paquetes más de 10 ficheros. Por supuesto dependerá del lenguage, o sea que la regla puedes adaptarla a tu criterio. La idea es hacer tu código lo más legible posible y fácil de mantener.7. Evita más de dos atributos de instancia.
Esta es casi imposible de seguir, pero aporta cohesión y mejor encapsulamiento. Una imagen vale más que mil palabras:8. Colecciones como clases de primer orden.
Cualquier clase que contenga una colección no debería contener más miembros. Si tienes una colección de elementos y quieres manipularlos, crea una clase dedicada a esa colección.9. Evita getters/setters o atributos públicos.
La manera más sencilla de evitar los setters es manejar esos valores en el constructor. Esto también es util cuando quieres hacer un objeto inmutable. Esta bien usas accessors (denominamos mutators a los setters y accessors a los getters) para obtener el estado de un objeto, siempre y cuando no se use el resultado para ejecutar lógica fuera del objeto. Cualquier cambio de estado del objeto debería realizarse dentro del objeto. Es por esto que se considera a los getters/setters mala practica. No hagas esto:// Game
private int score;
public void setScore(int score) {
this.score = score;
}
public int getScore() {
return score;
}
// Usage
game.setScore(game.getScore() + ENEMY_DESTROYED_SCORE);
Haz esto:
// Game
public void addScore(int delta) {
score += delta;
}
// Usage
game.addScore(ENEMY_DESTROYED_SCORE);
Comentarios
Publicar un comentario