¿Qué es One And Only Once?
Este no es un modelo, puesto
que no se puede aprender o enseñar en un periodo muy corto de tiempo, es decir
no es una regla simple, sin embargo es parte primordial en el diseño de
software. Once And Only Once se
considera que es parte del principio “Don’t You Repeat Yourself” (No te
repitas), siendo una de las máximas del desarrollo de software, determinando
que cualquier procedimiento dado en un sistema de información puede definirse
una y únicamente una vez. Los errores más comunes se dan por la duplicación de
los procedimientos, esto ocasionado por la gran posibilidad que existe de que no
sean definidos de la misma manera en todas las ubicaciones donde se encuentre. Es
por esta razón que se da origen a la creación de funciones y clases dado que
estas permiten la reutilización de instrucciones o procedimientos que son
definidos una única vez, y haciendo una llamado a estas se pueden ubicar en
cualquier parte del cuerpo de la aplicación, evitando la duplicación.
¿Qué
busca?
En un buen diseño de
software se busca por excelencia reducir la duplicación de comportamientos,
puesto que se desea que a un mismo problema sin importar la cantidad de veces
que se repita se le pueda dar solución una sola vez. Además de que los costos
de mantenimiento de software se ven incrementados si existe mucha duplicación
en su contenido, dado que los expertos deben repetir el trabajo sobre los
elementos duplicados.
En muchas ocasiones se puede
dar el caso de que se modifica o resuelve un problema que se está presentado en
el software sin saber si este ya ha sido resuelto con anterioridad por otro
experto en otra parte del código.
Básicamente esto es lo que
se busca evitar con la aplicación del Once And Only Once.
¿Por qué usar One And Only Once?
1.
Dado que hace posible que las modificaciones
en los sistemas se realicen de una manera más fácil y rápida.
2.
One And Only Once retiene entropía, que es la
tendencia de los sistema a desgastarse, a desintegrase para el relajamiento de
los estándares y un aumento de la aleatoriedad
3.
Es un instrumento de habilidad de diseño.
Herramientas de One And Only Once
·
Clases
internas:
o
Crear jerarquía de clases (herencia)
·
Patrón
de diseño comando
o
Hacer uso de los casos de polimorfismo
Tell,
don’t ask
En la programación procedimental, acostumbramos ver a los
datos como receptores de información solamente. En la programación con
objetos, el principio”Tell, Don’t Ask” nos va a llevar a darle inteligencia.
“Tell, don’t ask” nos
recuerda que no debemos usar los objetos para pedirles cosas y tomar
decisiones después, lo que debemos hacer es decirles a los objetos que hagan
cosas para que éstos internamente tomen sus propias decisiones según su estado.
Si lo hacemos bien, evitaremos un acoplamiento entre objetos, conseguiremos
sistemas más robustos y escalables. Y es que un objeto se define por
su comportamiento.
Por lo tanto, cuando hablamos de “Tell, don’t ask” hablamos
de cohesión,
y se refiere principalmente al grado de cercanía entre los elementos de
una clase (objeto).
Una cohesión alta se asocia con aspectos como la robustez,
la fiabilidad, la reutilización y la comprensión. Por el contrario, una
cohesión débil se asocia a aspectos menos deseables, como pueden ser la dificultad
de mantenimiento, de testear, de reusar y por supuesto de entender.
Una de las principales características que debe cumplir la
cohesión entre objetos es que éstos ocultan su funcionamiento interno, entre
otras cosas esto ayuda a evitar el acoplamiento y a entender mucho mejor
como trabajar con un objeto.
“El
código procedural recibe información y luego toma decisiones.
El código orientado a objetos le dice a los objetos que hagan cosas.”
El código orientado a objetos le dice a los objetos que hagan cosas.”
– Alec Sharp
Beneficios de seguir los principios “Tell, don’t ask”.
1.
Mayor encapsulación.
2.
Más cohesión en los objetos.
3.
Bajo acoplamiento.
4. Te ayuda a
enfocarte en el comportamiento de sus clases y en las funcionalidades
que deseas que se expongan.
Este principio casa perfectamente con la idea de que un objeto se define
por su comportamiento; y además es fundamental para sacar partido al polimorfismo y
la inversión de control. Es decir si nos dedicamos a preguntar y tomar nosotros
las decisiones estaremos acoplándonos, será prácticamente imposible hacer
cambios al objeto, estaremos incumpliendo el principio Open/Close,
nuestro sistema será más difícil de mantener. Al exponer el estado de una
clase a las demás para que pueda ser manipulada estamos violando su
encapsulamiento y asumiendo riesgos, además de que estamos moviendo
responsabilidades a las clases de mayor nivel.
El principio fundamental de la programación orientada a objetos es la
unificación de métodos y datos, por lo que lo correcto es que cuando una clase
requiere conocer el estado de otra, es importante evaluar que uso se le darán a
esos datos, y realizar el procesamiento de esa información en la clase
expuesta, evitando la dispersión y propagación de estado.
En otras palabras, un
objeto para poder usarlo siempre lo tienes que crear primero. La idea es que un
objeto realiza una serie de funciones (sabe hacer una cosa). Cuando desde otro
sitio quieres utilizar esas funciones, necesitas una referencia a ese objeto y
llamarlo para que él haga su trabajo. (Eso es el “Tell, Don’t ask”)
Ejemplo: Supongan que
tienen un objeto de carrito de compra, que contiene todos los artículos que ha
comprado un cliente. Si ahora quieres saber el total de la compra podrías
pedirle al carrito la lista de artículos, iterar por ella, e ir sumando los precios.
Esto viola el Tell, Don’t ask. Para hacerlo bien lo correcto sería pedirle al
carrito de la compra el total de la compra, ya que es el carrito quién tiene
los artículos (es decir no le estamos preguntando al carrito que artículos
tiene, sino que le estamos diciendo que nos haga él el cálculo del total).
Cuando antes decía
que “necesitas una referencia a ese objeto”, aquí es donde tú puedes crear la
instancia del objeto o donde te la pueden pasar de alguna manera (en el
constructor, en un método, incluso en un service locator). Aquí es donde
conseguimos la “inversión de control”, ya que, como no conoces el origen del
objeto, gracias al polimorfismo te podrían pasar otra implementación y tú
código sería el mismo, no tendrías ni que cambiarlo ni recompilarlo ni hacer
nada.
Pregunta
por el resultado, no por los datos.
En lugar de preguntar por los datos:
 1
2
3
4
|
Age age = sebastian.getAge();if (age
>= 18) { letDoTheThingsThatAdultsDo(sebastian);} |
Pregunta por los resultados:
 1
2
3
|
if (sebastian.isAdult()){ letDoTheThingsThatAdultsDo(sebastian);} |
Lo que nos interesa saber en este ejemplo, es si Sebastian es
mayor de edad, si la mayoría de edad es de 18 o 21 no importa. Además el código
es mucho más limpio y claro si cumplimos el principio “Tell don’t ask”.
¿Cómo ves tus objetos, como simples containers
de datos o como emisores y receptores de mensajes para que hagan cosas?.
Grupo MySQL
Andreína Mayo
Andreína López
Se puede decir que es una herramienta que nos ayuda a reducir o a evitar la duplicación de comportamientos dentro de un diseño del software debido aque aumenta innecesariamente el número de líneas de código, y está comprobado que a más líneas de código (no necesarias) más complejo es el mantenimiento y más rápidamente crece la entropía, esto implica que si hay que cambiar ese código repetido… hay que cambiarlo en muchos sitios. Hay que buscar todas las repeticiones. Y si se nos olvida cambiarlo en algún sitio… el software acaba siendo incoherente, “diciendo” cosas diferentes para la misma funcionalidad requerida. Por ello baja la productividad y aumenta la probabilidad de error.
ReplyDeleteNormalmente un problema de duplicación de código esconde un problema de, o de falta de, diseño software. Por ello, duplicar código no es buena idea, más aún hoy que existen muchas herramientas de software libre que detectan facilmente el código repetido, como lo hace One And Only Once.
Como se menciona anteriormente esta buena practica no es un patrón a seguir, es mas bien un principio primordial para diseño y desarrollo de software de calidad que establece que cualquier comportamiento dado en una aplicación es definida solo una vez, lo que busca esta practica es que un problema sea solucionado una sola vez independientemente de cuantas veces se presente este después. Cabe agregar que esta técnica se debe utilizar porque permite que el código sea más sencillo de cambiar o modificar. Sobre el “Tell, don’t ask” se podría agregar que esta buena practica principalmente se aplica cuando existen violaciones a la Ley de Demeter, como por ejemplo el caso de Feature Envy, es decir, cuando se tiene una clase que intenta saber demasiado sobre otra, para evitar esto se debe pasar la lógica al objeto que contiene la información, en lugar de extraer de él la información y procesarla fuera. Para aprovechar estas técnicas es necesario conocer las implicaciones que conlleva aplicarlas o dejarlas de aplicar, dado que resulta bastante difícil encontrar reglas que se puedan usar siempre por lo que es necesario conocer y analizar las ventajas o desventajas al implementarlas.
ReplyDeleteEs importante esta buena practica porque como ya se ha mencionado antes mas que una herramienta o principio, esta buena practica nos ayuda ya que hace posible que las modificaciones en los sistemas se realicen de una manera más fácil y rápida. Un punto interesante que mencionaron en los beneficios es que nos ayudan a enfocarnos en el comportamiento de las clases y en las funcionalidades que deseamos que se expongan, lo que deja ver que esta practica es muy ventajosa para cualquier desarrollador. Aunque el principio hay algo que me genero duda, ya que dicen que si existe duplicidad en el contenido, se incrementa el costo de mantenibilidad del software y los expertos tendrán mas trabajo, lo que me deja ver que no es ventajosa..... Yorgelis comento algo que llama la atención y es el hecho de reducir la duplicidad, como ella dice, esta practica lo que busca es que un problema sea solucionado una sola vez sin importar cuantas veces se repita, pero por lo que mencione puede haber mucha duplicidad y generarnos mayor trabajo. Otro punto que abarcaron en este articulo es el “Tell, don’t ask”; el principal detrás de "Dime, no pregunte", es que debes decirles a tus objetos lo que quieres que hagan, en lugar de preguntarles sobre su estado y realizar llamadas adicionales, en la respuesta. Esto encapsula la lógica de negocios en el lugar correcto y puede evitar que las propiedades mutables se filtren a clases externas donde su estado puede modificarse incorrectamente, lo que provoca un efecto directo y negativo en el estado general del sistema.
ReplyDeleteCuando se habla de Software, podemos encontrar una gran cantidad de procesos inmiscuidos dentro de ella. Sin embargo en esta ocasión no generalizaremos, hablaremos específicamente de uno realmente fundamental en el área de la ingeniería del Software y se trata del diseño, ahora bien al hacer acopio de Once And Only Once que es considerada una de las máximas del desarrollo de software ya que esta pretende que al hacer uso de ella se hagan buenos diseños, buscado minimizar la duplicidad de comportamiento en los objetos además de los costos de mantenimiento y que las modificaciones en los sistemas se realicen de una manera más fácil y rápida.
ReplyDeleteEsta idea va en sincronía perfectamente con lo que veíamos en la definición inicial y la idea de que un objeto se define por su comportamiento; es decir si nos dedicamos a preguntar y tomar nosotros las decisiones estaremos acoplándonos, será prácticamente imposible hacer cambios al objeto, estaremos incumpliendo el principio Open/Close, nuestro sistema será más difícil de mantener, y por lo tanto más caro.
El “Tell, Don’t ask” es su esencia nos recuerda que no tenemos que usar los objetos para pedirles cosas y según la información que nos devuelven tomar decisiones, sino que lo que debemos hacer es decirles a los objetos que hagan cosas y estos objetos internamente tomaran sus propias decisiones según de su estado.
“One And Only Once”,“Tell, don’t ask” estos dos términos por así decirlo, son considerado como unos principios los cuales son utilizados en el desarrollo de software ya que se presenta errores comunes como es el caso de la duplicación de comportamiento, entonces tratando por separados estos principios, el primero “One And Only Once” se basa en reducir o eliminar la duplicación causada, además esta es unas de las principales razones para refactorizar y también es el núcleo de muchos patrones de diseño. Por otra parte como resaltan aquí el término “Tell, Don't Ask” se puede decir que consiste en agrupar datos con las funciones que operan con esos datos, además el principio “Tell, Do not Ask” proporciona un código mucho más fácil de entender y una garantía de compatibilidad mucho mejor. Esta herramienta al aplicarla traerá a nuestro software mejoría, calidad y eficiencia, ya que es unas de las buenas practicas que se pueden utilizar.
ReplyDeleteEl “Tell, Don’t ask” es un meme que nos recuerda que no tenemos que usar los objetos para pedirles cosas y según la información que nos devuelven tomar decisiones, sino que lo que debemos hacer es decirles a los objetos que hagan cosas y estos objetos internamente tomaran sus propias decisiones según de su estado.
ReplyDeleteEste meme casa perfectamente con lo que veíamos en la definición inicial y la idea de que un objeto se define por su comportamiento; y además es fundamental para sacar partido al polimorfismo y la inversión de control. Es decir si nos dedicamos a preguntar y tomar nosotros las decisiones estaremos acoplándonos, será prácticamente imposible dar el cambiazo al objeto, estaremos incumpliendo el principio Open/Close, nuestro sistema será más difícil de mantener
Con respecto a *one and only once* se puede decir que este método lo que busca es promover la reducción de la duplicación, dando como ventaja, reducir los costos cuando se esta desarrollando un software que presenta algún problema y mediante este proceso que no se vuelva redundante a la hora de solucionarlo, es decir, busca producir un código más limpio. One and only once, no es considerado como tal un patrón sino más bien un principio en el que cualquier comportamiento dado dentro de la aplicación pueda definirse sólo una vez.
ReplyDeletePor otra parte se encuentra el *Tell, don´t ask* también considerado un principio, en el que hace referencia a que no debemos usar los objetos para pedirles cosas y de acuerdo a la información que nos proporcionen poder sacar conclusiones y solucionar la situación sino que debemos volver a dichos objetos de cierto modo más independientes, es decir, que podamos pedirles algo y ellos internamente tomen sus propias decisiones y de acuerdo al estado en que estén logran solventar la situación. esto hace referencia a que un objeto realiza una serie de funciones(sabe hacer una cosa) y cuando desde otro sitio necesitas hacer uso de esas funciones, debes hacer una referencia de ese objeto y llamarlo para que pueda hacer su trabajo, en esto se basa *tell, don´t ask*
Tell-don’t-ask. ¿Vale la pena usarlo? En este post se han mencionado las ventajas que tiene usar este estilo de programación, pero creo que cómo todo debe tener sus desventajas o limitaciones y pues si las tiene, y es que impulsa a las personas a deshacerse de todos los métodos de consulta, los cuáles son muy útiles a la hora de simplificar. Además de eso se corre el riesgo de convertir nuestra clase en una especie de God Object (objeto Dios) que al conocer o hacer demasiado, concentra un montón de operaciones y viola el Principio de Responsabilidad Única, que establece que cada módulo o clase debe tener responsabilidad sobre una parte de la funcionalidad proporcionada por el software , y que la responsabilidad debe estar completamente encapsulada por la clase. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad.
ReplyDeleteAunque el tell don’t ask es una excelente guía para conseguir un diseño fácil de evolucionar, no deja de ser simplemente una guía, lo que sí es importante a la hora de diseñar un sistema es tomar en cuenta las ventajas y desventajas de los principios o herramientas que vayamos a utilizar para evitar inconvenientes al momento de desarrollar.
El principio de “Tell, don’t ask”. Es expresar, si necesitas cambiar el estado de un objeto, deja que ese objeto cambie su estado por ti. No tenemos que utilizar los objetos para pedirles datos y luego realizar operaciones con esos datos, sino que debemos de decirles a los objetos que ejecuten ellos esas operaciones por nosotros. El uso de variables globales crea dependencias ocultas y ésto puede desbocar a comportamientos inesperados en una aplicación. Por lo que cuanto más corto sea el tiempo de vida de una variable mucho mejor. Pero si una variable es global cualquiera se puede utilizar o cambiar su valor lo que puede llevar a errores inesperados. Cuando en una función o procedimiento se tiene una estructura similar con muchas partes en común y que solo cambia alguna variable, efectivamente estamos ante código duplicado. Y este código duplicado es un síntoma de problemas estructurales. Por ejemplo en la duplicación impuesta en este caso los programadores sienten que ellos no pueden elegir y parece que el entorno les fuerza a doblar el código debido a que algunas plataformas, como por ejemplo los navegadores, requieren su propio lenguaje lo que hacer tener que duplicar el código. Los propios lenguajes de programación tienen ciertas estructuras que ya doblan código como en c++.
ReplyDeletea programación modular ha venido avanzando notablemente, tanto que hoy en día visualizamos problemas que antes eran muy engorrosos para los programadores; resueltos de una manera sencilla. La modularidad de los segmentos otorga una gran ventaja a la hora de desarrollar un programa y es por ello vienen ciertos términos que nos hacen recordar como programar de una manera correcta, el termino "Tell, Dont Ask" hace referencia a que una función realiza una labor según el estado, es allí que viene lo que es el estudio de los parámetros asignados y la modularidad de segmentos en su máxima expresión. Otro termino que nos recuerda como debemos hacer un buen desarrollo es "One And Only Once" que tambien se relaciona mucho con el termino "Don't repeat Yourself" o no te repitas, es mas fácil y optimo utilizar segmentos modulares que tomen decisiones cuando son llamados que tener muchísimo código basura que solo ensucie nuestras lineas de desarrollo.
ReplyDeleteProgramar no es una labor sencilla ya que se deben tomar ciertos parámetros para hacerlo de una manera correcta, la consecución de todos los requerimientos, módulos, características y propiedades no son fáciles de obtener, es allí donde entra la parte de modelar antes de diseñar, para que, a la hora de escribir código, tener una armonía que le permita a nuestro diseño ser fuerte en toda circunstancia.
Este tipo de buenas prácticas nos ayudan mucho a la hora de la reducción de manteniendo de costos de software ya que mediante el buen diseño de este minimiza la duplicación de comportamientos, también nos ayuda que sea más fácil y rápidas la modificaciones en el sistema
ReplyDeleteLos patrones de diseño nos proporcionan pautas para ayudarnos a implementar un código de mantenimiento claro y conciso. Al implementar el diseño orientado a objetos, tanto la tipificación de pato como el patrón Tell Do not Ask van de la mano para producir código fácil de componer y de mantenimiento. Además, la programación funcional y las técnicas de interfaz comunes, como las Mónadas por diseño, implementan Tell Do not Ask.
Cuando hablamos de Once And Only Once, nos referimos a uno de los principios de la programacion mas importante, el cual nos permitirá optimizar de mejor manera los recursos, que basicamente propone la no repetición de codigo. A simple vista este principio parece ser bastante simple, sin embargo no es tan facil aplicarlo como se cree. Muchos programadores con años de experiencia tienden a tener aun errores en este aspecto, hay que tener claro que Once AndOnly Once no es un patrón. Un patrón es algo que puede enseñarse a alguien a hacer en un período de tiempo bastante corto. Un día, por lo general. Quizás unas semanas. Pero aprender cómo refactorizar clases es algo que toma muchisimo tiempo, Once And Only Once no es un patrón es un principio. Ahora hablando de "Tell, Don't ask", este principio dice que en lugar de pedirle a los objetos datos, debemos decirles que hacer y esperar el resultado de esa acción, con esto evitamos usar la información interna de los objetos para tomar decisiones fuera de ellos y luego pedirles que hacer o afectar su comportamiento interno.
ReplyDeleteBuenas prácticas a la hora de diñar un software o crear cualquier programa, es muy importante tenerlas presentes. “One and only one” (no es un patrón), es una regla que se encarga de supervisar el código, su principio es que no se repitan códigos, evitando así la duplicidad que es una de las fuentes más comunes de errores en los sistemas de software, permitiendo así como ya se comento anterior mente minimizar costes y evitar renundancias , permitiendo además que los sistemas sean más fáciles de modificar o cambiar . El “Tell, Don’t ask” es un principio que nos indica que no tenemos que usar los objetos para pedirles cosas y según la información que nos devuelven tomar decisiones, sino que debemos decirles a los objetos que hagan cosas y estos objetos internamente tomaran sus propias decisiones según su estado.
ReplyDelete“One and only once” que en su traduccion al español “una y solo una vez” pues su nombre se da debido a la manera en que se deberia codificar, osea evitar redundar codigo. Al aplicar este principio en nuestros proyectos evitaremos tener errores que sean dificiles de encontrar. Tell, Don't Ask Es una de las ideas que se considera buena en programación orientada a objetosy consiste en pasar la lógica al objeto que contiene la información, en lugar de extraer de él la información y procesarla fuera. La Ley de Demeter y el principio de tell, don’t ask son unas buena guías para intentar diseñar componentes poco acoplados y conseguir un diseño que sea fácil de evolucionar, pero no dejan de ser eso, guías.En el diseño de sistemas reales es difícil (¿imposible?) encontrar reglas que podamos seguir siempre, y es necesario estar continuamente analizando las ventajas e inconvenientes de aplicarlas.Lo más importante es tener claro cuáles son los conceptos subyacentes a todas esas leyes y principios que existen sobre el desarrollo de software para ser capaz de comprender qué implicaciones tiene aplicarlos y qué implicaciones tiene saltárselos.
ReplyDeleteAl diseñar nuestro sistema basándonos en estas buenas practicas tenemos que tener presente este principio, el cual tiene la finalidad reducir la repetición de patrones de software, reemplazándolo con abstracciones o utilizando la normalización de datos para evitar la redundancia. El principio DRY (Don´t Repeat Yourself) se establece como cada conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema. Lo aplican bastante para incluir esquemas de bases de datos, planes de prueba, el sistema de compilación, incluso la documentación. Cuando este principio se aplica con éxito, una modificación de cualquier elemento individual de un sistema no requiere un cambio en otros elementos lógicamente no relacionados. Además, los elementos que están lógicamente relacionados cambian de manera predecible y uniforme, y por lo tanto se mantienen sincronizados.
ReplyDeleteLeyendo de los demas comentarios puedo observar que todos estamos de acuerdo en que es definitivamente fundamental que para el desarrollo de software de calidad se realicen estas buenas practicas publicadas en el post, siempre hay que tener en cuenta el ahorro de recursos importante como el tiempo, los espacios de memoria, y fundamentalmente el desempeño de los sistemas a desarrollar. Aplicando esos modelos de desarrollo como One And Only Once se pueden lograr ese tipo de resultados que a la larga terminaran gustando a los usuarios finales, los cuales son siempre los que dan la ultima palabra y le dan el verdadero valor al sistema. Con la practica Tell, Dont Ask pasa algo similar aunque los enfoques en el desarrollo son distintos, pero se logra lo que he mencionado anteriormente con respecto a las mejoras en el desempeño de los sistemas.
ReplyDeleteEsta buena practica es interesante y el blog lo describe de buena manera. Como muchos ya han mendionado en comentarios anteriores esta buena practica debería tratar de decir a los objetos lo que quiere que hagan, en pocas palabras, así no les hace preguntas sobre su estado, tome una decisión y luego díce qué hacer. No obstante, esta buena practica se utiliza específicamente y usualmente para casos en los que cambia el estado del objeto después de que lo solicitó, aunque este no es siempre el caso, por ejemplo, tengo un objeto 'usuario' que no se cambia después de que se le pidió su dirección de usuario. Por lo tanto, es discutible si este es un caso apropiado para aplicar Tell, Dont-Ask. Cabe agregar que este tipo de buena practica tiene que ver con la responsabilidad, sin sacar la lógica de una clase que debería estar justificada dentro de ella. Pero no toda la lógica que trata con objetos es necesariamente lógica de esos objetos. Esto sugiere un nivel más profundo, incluso más allá de Tell-Dont-Ask pero eso ya sería una investigación más detallada. OJO, esta buena practica como dijo Yorgelis no es un patrón a seguir, es una simple guía como comento Dayani, esto con el fin de realizar un diseño y desarrollo con eficacia.
ReplyDelete