El capítulo describe las buenas prácticas para organizar clases en Java. Las clases deben tener una única responsabilidad, tamaño reducido, alta cohesión y encapsular datos y comportamientos relacionados. Además, las clases deben organizarse para facilitar cambios futuros sin afectar otras áreas del código.

1. Clean Code, Capítulo 10:
Clases.
Esteban Vallejo Morales

2. Agenda
• Organización de clases
• Encapsulación
• Las clases deben ser de tamaño reducido
• El principio de responsabilidad única
• Cohesión
• Mantener resultados consistentes
• Organizar los cambios

3. Organización de clases
Según la convención estándar de Java, una clase:
• Comienza con una lista de variables.
• Primero, constantes estáticas públicas.
• Segundo, variables estáticas privadas.
• Tercero, variables de instancia privadas.
• Las funciones públicas deben seguir a la lista de variables.

4. Encapsulamiento
• Si una regla del mismo paquete tiene que invocar una función o acceder a
una variable , hacemos que tenga ámbito protected o de paquete

5. Las clases deben ser de tamaño reducido
• Con las funciones medimos el tamaño contando líneas físicas. Con las clases
usamos otra medida distinta: las responsabilidades.

6. Tamaño de la clase
Mal Bien

7. Pero…
• No solo hay que cuidar que no tenga muchos métodos, sino cuidar
especialmente que la clase no tenga muchas responsabilidades.
• Una clave para identificar las responsabilidades es asociar a las mismas con el
nombre de la clase.
• Cuanto mas ambiguo sea el nombre de una clase más probabilidades hay de
que tenga demasiadas responsabilidades.
• Otra clave es que a la hora de describir la clase no nos encontremos con
palabras como “y”, “o”, “si”, “pero”.

8. Principio de responsabilidad única
• Las clases solo deben tener una responsabilidad y por ende, solo un motivo
para cambiar.
• Podemos extraer los tres métodos de SuperDashBoard relacionados con la
información de versiones en una clase independiente como Version. La clase
Version es una construcción que se puede reutilizar en otras aplicaciones.

9. Principio de responsabilidad única
• En conclusión: “Los sistemas deben estar formados por muchas clases
reducidas, no por algunas de gran tamaño. Cada clase reducida encapsula una
única responsabilidad, tiene solo un motivo para cambiar y colabora con
algunas otras para obtener los comportamientos deseados del sistema”

10. Cohesión
• Las clases deben tener un número reducido de variables de instancia.
• Los métodos de una clase deben manipular una o varias de dichas variables.
• Cuantas más variables manipule un método, más cohesión tendrá con su
clase.
• Una clase en la que cada variable se usa en cada método tiene una cohesión
máxima.
• La idea es crear una dependencia lógica entre métodos y variables.

11. Ejemplo de cohesión

12. Mantener resultados consistentes en clases de
tamaño reducido
• La división de grandes funciones en otras más pequeña aumenta la
proliferación de clases.
• Si necesito que dentro de una función 1 se llame a una función 2, en lugar de
mandarle a ésta las variables declaradas en la función 1, estas variables
hacerse de instancia o globales en la clase pero esto implica que se pierda
cohesión ya que acumularían más y más variables globales que solo existen
para que otras funciones las compartan.
• Cuando esto sucede es conveniente crear otra clase.

13. Organizar los cambios
• En muchos sistemas el cambio es continuo. Cada cambio supone un riesgo
de que el resto del sistema no funcione de la forma esperada. En un sistema
limpio organizamos las clases para reducir riesgos en los cambios.
• En un sistema ideal, incorporamos nuevas funciones ampliándolo, no
modificando el código existente. Esto nos lleva a crear subclases que eviten
que dos funcionen se relacionen tanto que el cambio en una afecte a la otra.
Esta decisión facilita además la realización de pruebas.

14. MUCHAS GRACIAS