Siguiendo con la acciones de mejora / compartiendo videos cleancoders, continuamos con los resumenes de los capítulos de Clean Coders.
En este caso, nos toca el Capitulo 4. Como este capitulo es bastante denso es posible que termine haciendo varios posts relacionados, pero de momento, en este post me voy a centrar en las conclusiones más importantes del capitulo.
En este caso, nos toca el Capitulo 4. Como este capitulo es bastante denso es posible que termine haciendo varios posts relacionados, pero de momento, en este post me voy a centrar en las conclusiones más importantes del capitulo.
Cap 4 - Estructura Funciones (Conclusiones)
- Los prototipos de funciones deben ser pequeños, pocos argumentos (<=3), no pasar booleans, ni usar argumentos que puedan ser null, no argumentos de salida
- Las funciones se organizan siguiendo la regla de step down, lo publico primero, lo privado después y siempre intentando que las funciones a las que llama cada función estén debajo de la definición de esta primera función y descendiendo cada vez en abstracción.
- Switch va en contra del paradigma OO e interfiere en el despliegue independiente de componentes (y por tanto en el desarrollo independiente) .
- Debemos remplazar los switchs por polimorfismo o por lo menos mover los switchs a sitios donde no generen ese problema de dependencias (por ejemplo a una factoria o al main).
- El Temporal coupling en muchos casos se puede limitar o eliminar usando el patrón de pasar un bloque.
- Conviene separar las funciones de query (consulta) de las de comando (modificación) (CQS)
- Tell don’t not ask
- No hacer cadenas de queries, evitar que una sola linea tenga gran conocimiento de la estructura de la aplicación o de gran cantidad de objetos. Recordando la Ley de Demeter... No se habla con extraños.
- Limitar el uso o eliminar de salidas de bucle desde dentro (break). Hacen menos entendible el código.
- Pensar en el control de errores antes que en el código normal
- Usar excepciones para el control de errores. (no devolver error codes)
- Las excepciones deben ser de la clase o modulo que las lanzas
- No check exceptions.
- funciones o gestionan errores o hacen cosas, no las dos cosas.