La importancia del diseño orientado a objetos
Si no lo lleva, no lo lleva
No sé dónde es que escuché esta frase tan popular en el sur de México pero aplica muy bien para lo que queremos explicar aquí: tenemos que comenzar a aplicar los principios básicos y de flexibilidad de la programación orientada a objetos.
Quizá nos ha pasado, al momento de crear una funcionalidad nueva para un programa que estamos recién escribiendo nos comenzamos a llenar de variables que, al menos en ese momento, tiene mucho sentido para nosotros y terminamos teniendo constructores larguísimos y setters y getters por todos lados. Pero cuando la funcionalidad ya está ejecutando su tarea nos damos cuenta, quizá no necesitábamos tantas variables. Entonces... ¿Qué hacemos? ¿Las dejamos ahí y le decimos a nuestro cliente que se adapte a ellas? Va a ser que no.
Al satisfacer una petición de nuestro cliente por alguna razón, cualquier razón es válida, no entendemos bien qué nos está pidiendo y es aquí cuando tenemos que comenzar a aplicar las buenas prácticas pues primero tenemos que tener una descripción textual del problema a resolver para evitarnos escribir sentencias inútiles que después cambiaremos cuando ya comprendamos bien de qué va el problema. Esto nos hará ahorrar nuestro recurso más valioso: el tiempo.
Encapsulando cosas
via GIPHY
Una de las buenas prácticas de la programación orientada a objetos que más destaca es la encapsulación. Este concepto nos permitirá agrupar nuestra aplicación en partes lógicas que hará que nuestras aplicaciones tengan más sentido al momento de resolver nuestro problema. Ojo aquí, más sentido al resolver nuestro problema. En el capítulo se nos sugería la creación de dos clases Guitar y GuitarSpec así que a primera vista, y sin las pistas obvias que nos da el libro, podríamos llegar a pensar que eso no sería una buena práctica. ¿Por qué crear dos objetos que en principio parecen ser lo mismo? Bueno, porque para nuestro problema en particular esto tiene muchísimo sentido.
La idea de encapsular las cosas es proteger información de una parte de nuestra aplicación a otras partes, sí, ya sabemos que existe la palabra private para eso pero presta un poco más de atención que no estamos hablando de protegernos nuestras variables o métodos para con el usuario pilluelo, estamos hablando de proteger partes de la aplicación desde dentro. Quizá ahora mismo te estás dando cuenta que la encapsulación va más allá declarar todo como private.
Una de las bondades de la encapsulación es que nos ayudará a no repetir código. En el caso de Rick la encapsulación nos permitió romper en partes nuestra app y cuando nos tocó modificar añadir una nueva característica a la clase Guitar no tuvimos que cambiar totalmente todas las demás clases. Quizá deberíamos de tomarnos la encapsulación más en serio y romper en partes nuestro código más seguido.
Moraleja
La encapsulación sólo es uno de los principios básicos del desarrollo orientado a objetos así que no pierdas el tiempo, comienza a buscar los demás. Si no tienes ni idea de por dónde empezar puedes comenzar con herencia y polimorfismo. ¿Qué aprendimos hoy? Bueno, cuando nuestro parte del código ya haya solucionado el problema de nuestro cliente ahora sí podemos comenzar a buscar código duplicado y mal diseño de clases, pero recuerda, sólo cuando ya hayamos resuelto el problema base.
Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados.
Quizá nos ha pasado, al momento de crear una funcionalidad nueva para un programa que estamos recién escribiendo nos comenzamos a llenar de variables que, al menos en ese momento, tiene mucho sentido para nosotros y terminamos teniendo constructores larguísimos y setters y getters por todos lados. Pero cuando la funcionalidad ya está ejecutando su tarea nos damos cuenta, quizá no necesitábamos tantas variables. Entonces... ¿Qué hacemos? ¿Las dejamos ahí y le decimos a nuestro cliente que se adapte a ellas? Va a ser que no.
Al satisfacer una petición de nuestro cliente por alguna razón, cualquier razón es válida, no entendemos bien qué nos está pidiendo y es aquí cuando tenemos que comenzar a aplicar las buenas prácticas pues primero tenemos que tener una descripción textual del problema a resolver para evitarnos escribir sentencias inútiles que después cambiaremos cuando ya comprendamos bien de qué va el problema. Esto nos hará ahorrar nuestro recurso más valioso: el tiempo.
Encapsulando cosas
Una de las buenas prácticas de la programación orientada a objetos que más destaca es la encapsulación. Este concepto nos permitirá agrupar nuestra aplicación en partes lógicas que hará que nuestras aplicaciones tengan más sentido al momento de resolver nuestro problema. Ojo aquí, más sentido al resolver nuestro problema. En el capítulo se nos sugería la creación de dos clases Guitar y GuitarSpec así que a primera vista, y sin las pistas obvias que nos da el libro, podríamos llegar a pensar que eso no sería una buena práctica. ¿Por qué crear dos objetos que en principio parecen ser lo mismo? Bueno, porque para nuestro problema en particular esto tiene muchísimo sentido.
La idea de encapsular las cosas es proteger información de una parte de nuestra aplicación a otras partes, sí, ya sabemos que existe la palabra private para eso pero presta un poco más de atención que no estamos hablando de protegernos nuestras variables o métodos para con el usuario pilluelo, estamos hablando de proteger partes de la aplicación desde dentro. Quizá ahora mismo te estás dando cuenta que la encapsulación va más allá declarar todo como private.
Una de las bondades de la encapsulación es que nos ayudará a no repetir código. En el caso de Rick la encapsulación nos permitió romper en partes nuestra app y cuando nos tocó modificar añadir una nueva característica a la clase Guitar no tuvimos que cambiar totalmente todas las demás clases. Quizá deberíamos de tomarnos la encapsulación más en serio y romper en partes nuestro código más seguido.
Moraleja
La encapsulación sólo es uno de los principios básicos del desarrollo orientado a objetos así que no pierdas el tiempo, comienza a buscar los demás. Si no tienes ni idea de por dónde empezar puedes comenzar con herencia y polimorfismo. ¿Qué aprendimos hoy? Bueno, cuando nuestro parte del código ya haya solucionado el problema de nuestro cliente ahora sí podemos comenzar a buscar código duplicado y mal diseño de clases, pero recuerda, sólo cuando ya hayamos resuelto el problema base.
Recuerda que siempre puedes visitar la página de O'REILLY y comprar el libro del cual estos post están basados.
Comentarios
Publicar un comentario