FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Hola mamcx
Esa es la cuestión. Tal y como cita Neftali (hola de nuevo) de mi primer post: "Mi duda está realmente en el concepto (porque el código, funcionar, funciona). Es decir, en un "sitio" donde recupero un valor... lo cambio también (y antes de devolverlo)" En cuanto a lo de crear 2 clases... tengo que pensar en ello con más calma, pero apriori (en este caso) no me convence. ¿Por qué? Pues porque realmente la clase hace "un solo trabajo" pero (siempre hay un pero) como el usuario puede con sus propias manos tocar y cambiar.... estaba buscando maneras de minimizar sus efectos... y, de rebote, llegué a este tema. Se me ocurrió que, sin encomendarme a Dios ni al Diablo, podía "pasarme por la piedra" el estado real y poner el que yo quiero. Es decir que, como "no me importa" el real, cada vez que quiera saber el estado del objeto reviso el real y lo cambio directamente (porque, repito, el estado real NO importa) matando dos pájaros de un tiro. ¡buff! me resulta un poco difícil explicarlo... pero seguiré dándole vueltas (es bueno pensar de vez en cuando)... En cualquier caso me resulta algo, como decía antes, raro (el hacerlo así) y por eso abrí este hilo
__________________
La violencia es el último recurso del incompetente. (Salvor Hardin) |
#2
|
||||
|
||||
Hola marto
Pues sí... buen link... Lo que me pasa es algo parecido... pero yo no puedo tener un semáforo que me diga si algo ha cambiado porque los cabios no se hacen a través de la aplicación sino a mano (literalmente) por el usuario... pero el "recalculate" de Ian sería el "UpdateEstado" del que escribía Neftali más arriba pero puesto en el Get no en el Set ¿no?
__________________
La violencia es el último recurso del incompetente. (Salvor Hardin) |
#3
|
||||
|
||||
Wop!
con el link al artículo de Marteens lo que quería decir es que tú (y Neftali y Lepe) tienes razón y que en el Get se puede modificar perfectamente el valor de la propiedad, si no, no le programes un get y lee directamente la variable. Ah! Y Lepe ya te lo proponía en el Get!
__________________
E pur si muove |
#4
|
||||
|
||||
Deberias leer con mas detalle la explicacion de Marteens... en ningun momento dice que una propiedad CAMBIA el valor de otra, sino que mas bien el acceso a una propiedad OBLIGA a RE-LEER las demas. El principio al que alude es a que solo se conoce la realidad de un objeto en un momento X del tiempo (tal como postula la fisica cuantica), pero al ir avanzando la realidad va cambiando, tonces, se debe reexaminar los datos. Pero imaginate que la temperatura cambia la direccion y la direccion altera la velocidad... eso ya no es incertidumbre sino caos!
__________________
El malabarista. |
#5
|
||||
|
||||
Cita:
__________________
E pur si muove |
#6
|
||||
|
||||
Si miras el codigo que esta al inicio vez que se reasigna el valor de Estado. Y vez que se leen dos estados (Result es asignado dos veces desde fuentes de datos diferentes: La clases como tal por la variable interna y por medio del OCX). Es por eso que se hizo la pregunta en primer lugar.....
__________________
El malabarista. |
#7
|
||||
|
||||
Tienes razón mamcx, el código inicial... pero no me he limitado a esperar respuestas
He ido trabajando en ello y cambiando lo necesario... De hecho vuestras respuestas han sido MUY útiles... Habéis conseguido que entienda mucho mejor lo que estoy haciendo (estaba mezclando churras con merinas). Ahora la propiedad solo se cambia en el set... donde además cambio el estado físico del teléfono. Muchas gracias a todos.
__________________
La violencia es el último recurso del incompetente. (Salvor Hardin) |
#8
|
||||
|
||||
Está claro que el método GET puede alterar las variables internas pero sin embargo mamcx tiene razón.
Al inicio de esta discusión Ohcan escribe: Cita:
Código:
function GetPropiedad: Tipo; begin Calculos; // "muchos" cálculos que determinan FPropiedad Result := FPropiedad; end; Esto debiera ser claro paro todos (sólo que a Marteens le encanta filosofar), es la esencia de los métodos GET. De lo contrario, como dice marto, nos bastaría leer directamente el valor de FPropiedad. Pero, de las dos posibles soluciones que plantea Ohcan, lo que dice Marteens (y cualquier libro de OO) corresponde a la primera, no a la segunda, que es la que Ohcan desea. El mismo Ohcan admite Cita:
Y ese pero lo molestará en un par de semanas o meses cuando tenga que revisar el código porque no es lógico. // Saludos |
#9
|
||||
|
||||
¡Vaya! no pensaba que fuera a ser un tema tan polémico...
En cualquier caso he seguido trabajando en el tema... porque aunque funcionaba tal cual... no me gustaba la solución. mamcx, he llegado a una conclusión parecida a la tuya (buen ejemplo el de la temperatura). Recapitulo. Tenemos DOS partes: el objeto de programación y el teléfono. Qué es lo que quiero: que el teléfono tenga el estado (físicamente) que yo quiera. Por lo tanto: el que manda es el objeto. En el Get NO cambio la propiedad Estado de mi objeto. Simplemente, miro si el estado real del teléfono es válido (=valor de la propiedad) y, si no lo es, lo cambio (físicamente). La propiedad NO cambia, cambia el mundo físico . ¿Por qué tanto lío? Porque ni yo mismo me aclaro a veces... (ahora lo tengo más claro). Veréis: en el Set, cuando pongo FuncionOCX(ParametrosX) estoy cambiando físicamente el teléfono para ponerle en el estado del parámetro NuevoEstado y es entonces cuando le doy valor a FEstado. Creo que esto cambia un poco el sentido del hilo... Ahora en el Get llamo al Set (aunque no directamente sino con un procedimiento de update que lo llama) pero no para cambiar la propiedad sino para mantenerla... "No es caos sino statu quo" (perdona mamcx, es que me gustó mucho tu frase)
__________________
La violencia es el último recurso del incompetente. (Salvor Hardin) |
|
|
|