"Al dise帽ar nuestras clases debemos juntar las caracter铆sticas relacionadas, de modo que cada vez que cambien sea por la misma raz贸n. Y deber铆amos separar las caracter铆sticas que cambian por diferentes razones." 鉁嶐煆 Steve Fenton

Otra vez empezado fuerte con una frase que hay que desmenuzar para entenderla. La verdad es que casi todo hay que destriparlo para comprenderlo. Supongo que as铆 pensaba Jack the ripper...

Bromas macabras aparte, cuando esta regla no se cumple los problemas y dificultades en el mantenimiento aumentan. As铆 que merece la pena entenderla y despu茅s aplicarla.

Distribuir con criterio

La idea es que dadas n funciones que vas a distribuir en m clases, lo hagas con este criterio: junta en una misma clase las cambian por el mismo motivo. Y no metas en una misma clase aquellas que cambian por otros motivos. Ejemplos de motivos pueden ser estos:

  • Cada vez que cambie el c贸mo leemos o escribimos datos en un fichero.
  • Cada vez que cambia la pol铆tica de precios de nuestros productos.
  • Cada vez que validamos temas de seguridad.
  • Cada vez que mostramos alertas de proceso a los usuarios.

Si lo haces de esta manera, sabr谩s d贸nde hay que tocar para realizar cada cambio, en funci贸n del origen o tipo de cambio. Saber d贸nde hay que tocar es la primera parte de arreglar o modificar algo. Y es fundamental para no repetirlo en caso de que ya exista.

As铆 que vuelve a leer esta regla, aseg煤rate de entenderla y empieza a implantarla y difundirla.

馃憮 Los objetos encapsulan La L贸gica

Dado que la l贸gica se expresa en instrucciones dentro de las funciones. Y decimos que un m贸dulo, clase o como le llames, es un conjunto de funciones. Pues queda claro que esos objetos encapsulan, guardan, la l贸gica del programa.

馃摝 Usan estructuras de datos

驴Y los datos? Pues son recibidos, mantenidos, creados y enviados entre estos objetos. Son los argumentos de sus m茅todos p煤blicos. Son el resultado que retornan. Son la materia prima de los objetos.

馃懐 Cohesionan funciones relacionadas

Al cumplir las reglas y l铆mites del c贸digo limpio se acaban generando muchas, much铆simas funciones. Al cumplir con la regla de Fenton acabamos por cohesionar esas funciones en ficheros seg煤n un criterio; y evitamos que acaben desperdigadas, o lo que es peor, repetidas.

馃拺 Relacionan unas entidades con otras.

Un objeto no puede ni debe saberlo y hacerlo 茅l todo. Por fuerza ha de delegar en otros. Instanciar e invocar m茅todos de otras clases es la manera de relacionarse que tienen nuestros objetos. Es decir las relaciones entre las entidades.

馃懙 Interfaces mejor que herencia

Mas temprano que tarde aparecer谩n objetos que implanten l贸gica similar o incluso la misma pero en otro contexto. En P.O.O. t茅cnicamente podremos echar mano de la herencia para reutilizar c贸digo. Pero una vez m谩s, casi siempre va a ser una mala idea. La soluci贸n recomendada ser谩 declarar, implementar y depender de interfaces. Pero eso requiere un estudio aparte.

鈿狅笍 L铆mites

Cuanto m谩s avanzas en tu destreza y conocimiento del c贸digo y su expresividad, m谩s nos alejamos de recetas triviales. Muchos de los l铆mites que propongo en este curso se pueden recomendar a casi cualquier c贸digo con los ojos cerrados.

Pero llegados a tocar el core de la l贸gica... ya hay que hilar m谩s fino. De todas formas se pueden dar unas recomendaciones y establecer unos indicadores que nos alerten de si algo est谩 yendo mal.

  • 馃憠馃徏 4 鈫 16 馃憟馃徏 propiedades y m茅todos p煤blicos
  • 馃憠馃徏 0 鈫 2 馃憟馃徏 argumentos por m茅todo
  • 馃憠馃徏 0 鈫 1 馃憟馃徏 niveles de herencia
  • 馃憠馃徏 100 鈫 200 馃憟馃徏 instrucciones por clase

Una 煤ltima recomendaci贸n. Si todo va bien ver谩s que los m茅todos de tus clases usan con mucha frecuencia sus propios datos, es decir, sus propiedades. Desconf铆a de un objeto que usa demasiado o necesita saber demasiado de otros objetos.