En estas entradas, el término "calisténico" no hace referencia a ejercicios musculares (puedes encontrar información sobre eso aquí por ejemplo, o seguir buscando en google).
Ir a la introducción de esta serie.
Ir a post anterior.
4. Utiliza sólo una introducción punto por línea
Usa sólo un punto por línea. Este paso evita que tu código alcance profundamente a otros objetos para llegar a sus métodos o propiedades, y por tanto romper conceptualmente la encapsulación.
En definitiva, que te tienes que OlvidarDe.Llamar().AUnMetodo().TrasOtro() en la misma línea y UtilizarSolo.UnaLlamada()
De cara al interface público (es más, publicado) proporcionado al usuario de tus clases, no sé dónde se rompe la encapsulación. Encapsular es asignar cierta responsabilidad a un módulo (en el sentido de Parnas), y hacer que los secretos relacionados con dicha responsabilidad, por ejemplo algoritmos o estructuras de datos, queden efectivamente escondidos en ese módulo. Si quiero saber cuántos alumnos de Derecho reciben clase de un determinado profesor, ¿qué problema habría en escribir el siguiente código?
Universidad.EquipoDocente(idProfe).Docencia(Titulaciones.Derecho).Alumnos.Cuenta()
Por poner un ejemplo. ¿Dónde rompo la encapsulación? Es verdad que aumento la dependencia del usuario de un montón de objetos, y a lo mejor sería bueno crear una fachada, del estilo:
ServiciosDocentes.NumeroAlumnos(idProfe, Titulaciones.Derecho)
Pero al final, ¿no llevaría esto a tener una serie de clases con multitud de métodos, uno por cada ruta seguida a través de los puntos? Empiezo a pensar que esto va un poco de coña...
5. No abrevies los nombres
Esta restricción evita la "verbosidad" procedimental que se crea por ciertas formas de redundancia—si tienes que escribir el nombre completo de un método o variable, casi seguro que te llevará más tiempo pensar en su nombre. Y evitarás tener objetos llamados Pedido con métodos llamados enviarPedido(). En vez de eso, tu código tendrá más métodos del estilo Pedido.Enviar()
La traducción creo que no es muy buena (¿alguien sabe cómo se traduce "verbosity"?), así que lo pongo en el original.
This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().
Pues... totalmente de acuerdo. Es más ¿hay alguien que no lo haga así?
¡Espero vuestros comentarios!
No hay comentarios:
Publicar un comentario