Organización de Clases
Una clase debe ir declarando sus partes en el siguiente orden:
- Constantes estáticas publicas
- Variables estáticas privadas
- Variables de instancia privadas
- Funciones públicas
Se cumple de este modo la regla descendente y permite que el programa se lea como un articulo de periódico.
Encapsulación
La premisa es que nuestras variables y funciones de utilidad sean privadas pero no es imprescindible.
Tamaño
Las clases deben ser de tamaño reducido.
Con las funciones mediamos el tamaño contando lineas fisicas.
Con las clases medimos con las responsabilidades.
No tiene que ver el numero de metodos que tenga en su interior. Puede haber una clase con muy pocos metodos pero tiene mucha responsabilidad, y otra con muchos metodos y con la responsabilidad justa.
Nombre de la Clase
Si no podemos acertar en un nombre conciso( que expresa las ideas con pocas y adecuadas palabras) para una clase, seguramente sea una clase demasiado extensa.
Cuanto más ambiguo sea el nombre de la clase, más posibilidades hay que tenga muchas responsabilidades.
Debemos poder escribir una pequeña descripción de la clase en unas 25 palabras sin usar las palabras: «si»,»o», «y»,»pero».
Principio de Responsabilidad Única ( Single Responsability Principle, SRP)
Indica que una clase o modulo debe tener uno y solo un motivo para cambiar.
Crear software que funcione y crear software limpio son dos actividades diferentes.
Muchos tenemos un cerebro limitado y nos centramos en que el codigo funciones mas que en su organizacion limpieza.
El problema es que muchos creemos que hemos acabado cuando el programa funciona y continuamos al siguiente problema en vez de retroceder y hacer «refactor» del código, aplicando las reglas de responsabilidad única.
Todos los sistemas tienen una gran lógica y complejidad. Lo mejor que se puede hacer es organizarla en pequeños pedazos para que un programador sepa donde buscar y la comprenda.
En resumen:
- Los sistemas deben estar formados por muchas clases reducidas, no por pocas de gran tamaño.
- Cada clase reducida:
- Encapsula su única responsabilidad.
- Tiene un solo motivo para cambiar.
- Colabora con algunas otras para obtener los comportamientos deseados por el sistema.
Cohesión
Cuantas más variables de instancia manipule un método, mas cohesión( unión o relación estrecha entre personas o cosas.) tendrá con su clase.
Se busca que la cohesión sea elevada. Si se lograra, significaría que los métodos y variable de la clase dependen unos de otros y actúan como un todo lógico
class Biblioteca
def initialize
@numeroLibros = 0
@libros = []
end
def tamano
return @numeroLibros
end
def anadir(libro)
@numeroLibros += 1
return @libros.push(libro)
end
def eliminar_ultimo_elemento
if @numeroLibros > 0
@libros.pop
@numeroLibros -= 1
end
return @libros
end
end
Este ejemplo es una clase muy consistente, ya que en casi todos los métodos se usan ambas variables.
La estrategia de reducir el tamaño de las funciones y de las listas de parámetros suele provocar la proliferación de variables de instancia usada por un subconjunto de métodos.
Si esto sucede, siempre existe al menos una clase que intenta huir de la clase de mayor tamaño.
Debe intentar separar las variables y métodos en dos o mas clases para que las nuevas sean mas consistentes.
Cambios
En muchos sistemas el cambio es continuo. Las necesidades cambiaran y el código también.
Cada cambio supone un riesgo de que el resto del sistema no funcione.
Si se practica el Principio de Responsabilidad Única, el riesgo de que una función afecte a otra desaparece casi por completo. Desde el punto de vista de los test, resulta mas sencillo probar la lógica, ya que las clases de aíslan unas de otras.
Debemos estructurar nuestro sistemas para ensuciarlos lo menos posible cuando actualicemos con nuevas funciones o cambios.
En un sistema ideal, incorporamos nuevas funciones ampliándolo, no modificando el código existente.