Llamar al Set desde el Get

[Ohcan]

Hola a todos

Estoy creando un objeto que hereda de un OCX.
Se trata, entre otras cosas, de controlar con mi programa el estado de una máquina...
Yo quiero que la máquina (una especie de teléfono) sea controlada por el programa y no por el usuario :D
Pero el usuario puede (aunque no debe) :rolleyes: "meter mano"...

Os pongo un código de ejemplo:
La declaración:

type
//[...]
TEstados = (eDesconocido,eLibre,eOcupado); //Tipo de estados de la máquina
TMiObjeto = class(TElOCX) //Heredo de un OCX
protected
FEstado:TEstados;
private
procedure SetEstado(NuevoEstado:TEstados);
function GetEstado:TEstados;
public
property Estado:TEstados read GetEstado Write SetEstado;
destructor Destroy;override;
constructor Create(AOwner: TComponent);override;
end;
//[...]


Y la implementación:

implementation
{ TMiObjeto }
constructor TMiObjeto.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
//[...]
end;
destructor TMiObjeto.Destroy;
begin
//[...]
inherited Destroy;
end;
function TMiObjeto.GetEstado: TEstados;
var
Datos:WideString; //Luego no se usa
Modo:TOleEnum; //Estado real de la máquina
EstadoReal:TEstados;//Estado real de la máquina
begin
Result := FEstado; //Estado en que el programa dice que está
//Me devuelve le estado (Modo) real
FuncionOCX(Modo,Datos);
case Modo of
ctc_Ready: EstadoReal := eLibre;
ctc_NotReady: EstadoReal := eOcupado;
else
EstadoReal := eDesconocido;
end;
//Ahora....
if (EstadoReal<>eDesconocido) and //Si es desconocido es OK
(EstadoReal<>Result) then //Si el estado real no es el que debiera
begin
FEstado := eDesconocido; //Por la primera línea del SetEstado
Estado := Result; //Pongo la máquina en el estado que mi programa almacenaba
end;
end;
procedure TMiObjeto.SetEstado(NuevoEstado: TEstados);
begin
if (FEstado=NuevoEstado) then Exit;
case NuevoEstado of
eLibre: FuncionOCX(ParametrosA);
eOcupado: FuncionOCX(ParametrosB);
end;
FEstado := NuevoEstado;
end;
//[...]


Tengo definida una propiedad para el estado, y el programa es el que lo gestiona.
Mi duda es: he puesto en el GetEstado una comprobación. Miro si el estado registrado en mi programa es el mismo que el estado real del teléfono (por si el usuario...).
Si no es igual hago una llamada al SetEstado y lo cambio.
¿Es correcto llamar al Set desde el Get?

No sé si me he explicado bien :o ...
Os agradeceré cualquier sugerencia...

Un saludo

[Neftali [Germán.Estévez]]

...Mi duda es: he puesto en el GetEstado una comprobación. Miro si el estado registrado en mi programa es el mismo que el estado real del teléfono (por si el usuario...).
Si no es igual hago una llamada al SetEstado y lo cambio.
¿Es correcto llamar al Set desde el Get?
Hombre, yo hubiera utilizado la variable interna, en lugar de la propiedad... Pero tampoco me atrevería a decir que es "incorrecto".
Por otra parte, creo, aunque puedes probarlo para confirmarlo, que si desde el Get Accedes a la propiedad eso te va a provocar que "entres" otra vez en el Get y así sucesivamente, lo que te podría provocar un bucle infinito.

[Ohcan]

Hola Neftali

Gracias por contestar.
Ya está probado :) (con el código real)
Uso la propiedad (Estado := Result) para que salte el Set... lo necesito para que ponga el teléfono en el estado...
Tuve un bucle... porque en el Set preguntaba por el valor de la propiedad (primera línea) en vez de por la variable...

Mi duda está realmente en el concepto (porque el código, funcioar, funciona). Es decir, en un "sitio" donde recupero un valor... lo cambio también (y antes de devolverlo)... ¿¿??

[Lepe]

Sinceramente no lo sé. Pero en mi humilde opinión no es lógico que se cambie un valor al leerlo.


if (EstadoReal<>eDesconocido) and //Si es desconocido es OK
(EstadoReal<>Result) then //Si el estado real no es el que debiera


¿por qué el estado no es el correcto ?

Creo que ese código debe ir en otro sitio, es decir, en el constructor, o bien en una propiedad del tipo Active := true / false o en un método llamado OpenTelephone

En el constructor pones Festado en eDesconocido
En el método OpenTelephone, modificas el estado (es lógico hacer esto aqui), incluso puede ser una función que devuelva TRUE / FALSE si todo ha ido bien.

en el GetEstado, solo devuelves el valor de FEstado, ya que:
- Si no se ha llamado a OpenTelephone devolverá eDesconocido
- Si se ha llamado al método, devolverá el valor detectado en ese método.

Ya veremos que opinan los demás ;)

Un saludo

[Ohcan]

Hola Lepe

A ver cómo me explico...
El código que he colgado es un ejemplo simplificado...
Efectivamente en el constructor hay... de todo ;) ¡buff! pero eso "no importa"
La cuestión es: el estado puede cambiar porque el usuario "meta la mano" donde no debe (no puedo evitarlo, y lo hacen), pero mi aplicación es "la que sabe" en qué estado debería de estar (hay muchos más estados...) y también tengo implementado (en real) un control de "errores" sobre las funciones/procedimientos del OCX...
Quiero decir (que me voy por las nubes), cuando en mi programa consulto el estado tengo dos: el real (en el que está el teléfono) y el último que yo forcé con la alpicación. Pueden ser iguales ¡bien! o no.
Si no son iguales..... tengo 2 opciones:
1. Poner el estado de mi variable = al real
2. al revés, forzar al teléfono a ponerse en el estado que marca la variable.
Yo he elegido la segunda opción (porque el usuario no debería tocar nada).
Lo que pasa es que "me se" ocurrió forzarlo en el propio Get... y "me sonó raro". Me resulta algo así como "contraintuitivo" (mira que soy pedante)... y por eso os preguto vuestra opinión (no porque no me funcione, sino porque el saber no ocupa lugar ;) )

Así que, después del plastazo que acabo de postear, ... pues eso:
A ver qué pensáis :)

Saludos.

[Lepe]

Entonces solo queda hacer algo así:

function TMiObjeto.GetEstado: TEstados;
begin
UpdateEstado;
Result := FEstado;
end;


Sé que me vas a mandar a paseo por esta respuesta, ya que es idéntico a tu solución, pero no sé .... ¿parece más "elegante"? :confused:

Si no estas de acuerdo no te molestes en contestar.... ya sé que lo que vas a decir :D :D

[Ohcan]

:D :D :D

;) ¡Claro! :D ¡Tienes toda la razón! ;)

De hecho, en el código real, está como tú dices... porque además necesito un procedimiento updateEstado... :)
Pero en el ejemplo queda, creo, un poco más claro poniéndolo dentro... :D

Lo que pasa es que, de vez en cuando, se me va la olla... y... ¡me pongo a elucubrar! :) jejejeje

[mamcx]

La cosa es muy simple:

- Get es obtener el valor
- Set es asignarlo

O sea:

- JAMAS JAMAS JAMAS en un get se debe alterar el comportamiento/estado interno de un objeto
- JAMAS ignorar el punto anterior. Get es acceso de SOLO LECTURA
- En un set se DEBERIA leer la variable privada que guarda el ultimo valor (FEstado) por la simple y sencilla razon que el Get puede tener efectos sobre el componente, aun sin cambiar el estado de la varible.

Lo que estas buscando NO es un get ni un set. Es un procedimiento. En un procedimiento APARTE:

procedure DeterminarEstado
begin
//Haz lo que necesites
end;

Es OO basica independizar propiedades de eventos de procedimientos. Nunca mezclarlos para evitar dolores de cabeza.

Por lo tanto Estado debe retornar el estado del objeto. Mas bien deberias tener una funcion que devuelva el estado asignado por el usuario y en el metodo DeterminarEstado lees ambos y luego operas esta informacion y la asignas al estado Interno (propiedad estado) del objeto.

De hecho, estas MEZCLANDO DOS cosas. UNA es el objeto interno de tu programa. OTRA es la maquina externa. O sea, DEBERIAS tener 2 clases para representar ambas realidades y UNA clases que controle ambas. O sea:

TMiObjeto = class(TElOCX) //Heredo de un OCX // Representa el mundo interno de tu sistema
TMiTelefono = class(TElOCX) //Heredo de un OCX // Representa el mundo real del telefono

Por eso, cuando empiezes a sentir que una clases hace mas de un solo trabajo entonces la solucion es hacer una clase por trabajo. Y debe haber una controladora entre ellas. Es un poco mas de codigo pero es mas facil de entender y mejorar...

[Neftali [Germán.Estévez]]

Mi duda está realmente en el concepto (porque el código, funcioar, funciona). Es decir, en un "sitio" donde recupero un valor... lo cambio también (y antes de devolverlo)
No creo que sea incorrecto. Tal vez sería más correcto hacerlo en el SET.
Es decir, a ver si me explico:

AHORA: Tu almacenas un valor y al consultalo (GET) compruebas y devuelves el correcto.

VARIANTE: ¿Porque no hacer lo mismo en el SET?
Al hacer el SET comprobar y guardar el valor correcto, así en el GET ya no deberías coprobar ni cambiar nada, sólo devolver lo que hay.

Es lo mismo que está haciendo tú (que como ya te he dicho no lo veo incorrecto, sólo un poco raro ;)) pero en lugar de en el GET, en el SET.

No se si me he explicado bien, espero que me entiendas.

[marto]

- JAMAS JAMAS JAMAS en un get se debe alterar el comportamiento/estado interno de un objeto
- JAMAS ignorar el punto anterior. Get es acceso de SOLO LECTURA

Bueno, TODO es discutible... o almenos algun gurú (www.marteens.com) no está de acuerdo contigo.... El Principio de Incertidumbre de Heisenberg (http://www.marteens.com/trick2f.htm)

[Ohcan]

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 :)

[Ohcan]

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? :)

[mamcx]

El codigo que pones de ejemplo es correcto. Esta RELEYENDO las propiedades pero igual no deberia de OPERAR sobre ellas. Si estuviera leyendo un archivo es OK releer por ejemplo el CHECKSUM cuando se altere el Size del archivo... pero no asignar la fecha del mismo.

Mira las respuestas... cuantas dicen algo como "no se si estoy claro"
"espero que me entiendas" "a ver si me explico" ESO DEMUESTRA que el diseño de la clase esta fundamentalmente errado. NO quiere decir que no se pueda truquear aqui y alla... pero para que dificil si se puede facil? Un ejemplo:

TCarro
property Temperatura:Integer

Que crees que lee Temperatura? Es simple, se espera que Temperatura, que es una propiedad lea el dato que corresponde a Carro. Es el comportamiento esperado. Pero luego alguien dira: Y que de la temperatura exterior? Pues simple:

TCarro
property Temperatura:Integer
property TemperaturaExterior:Integer

Pero es que necesito hacer una correcion si la temperatura exterior es muy baja o alta debo aumentar/baja la temperatura del carro. Imaginemos que el condenado carro es de la NASA y va pa Marte y no queremos que se nos congelen los astronautas. Entonces... muevo a Temperatura en base a la Temperatura Exterior?

Pues chico... si se mete un VERBO en lo que estoy haciendo YA NO es una propiedad. Es un metodo. En OO lo mas dificil es llamar los objetos y sus partes Propiedades=Adjetivos Metodos=Verbos Eventos=Verbos con tiempo o de reaccion... y no se deberia alterar el significado de Adjetivo a verbo de solo porque si. Si fue enruedado para quien escribio la clase... como crees que sera para el siguiente que la use?

Es claro. Estado debe leer de TMiObjeto. El estado externo es OTRO estado. No debe una propiedad que lee un valor leer el significado de dos valores (a menos que devuelva un valor de tipo multiple como un recordset, una matriz o algo asi, pero no es la solucion aqui). Eso es complicar mucho las cosas....

Es mucho mas simple:


type
//[...]
TEstados = (eDesconocido,eLibre,eOcupado); //Tipo de estados de la máquina
TMiObjeto = class(TElOCX) //Heredo de un OCX
protected
FEstado:TEstados;
private
procedure SetEstado(NuevoEstado:TEstados);
function GetEstado:TEstados;
public
property Estado:TEstados read GetEstado Write SetEstado;
property EstadoExterno:TEstados read GetEstado;
function SincronizarEstado:TEstados;
destructor Destroy;override;
constructor Create(AOwner: TComponent);override;
end;


Entonces el comportamiento de la clase es obvio. Estado retorna el estado ACTUAL de la clase. EstadoExterno consulta el del telefono. SincronizarEstado asigna el estado correcto en base a los dos estados y retorna el nuevo estado.

[marto]

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!

[mamcx]

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!

[marto]

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.
¡Y eso es más de lo que hace Ohcan, que tansolo "RE-LEE" la propia propiedad estado!

[Ohcan]

¡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 :D.

¿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) :D

[mamcx]

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.....

[Ohcan]

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.

[roman]

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:


Si no son iguales..... tengo 2 opciones:
1. Poner el estado de mi variable = al real
2. al revés, forzar al teléfono a ponerse en el estado que marca la variable.
Yo he elegido la segunda opción (porque el usuario no debería tocar nada).
Lo que pasa es que "me se" ocurrió forzarlo en el propio Get... y "me sonó raro". Me resulta algo así como "contraintuitivo" (mira que soy pedante)... y por eso os preguto vuestra opinión (no porque no me funcione, sino porque el saber no ocupa lugar )


Por otra parte lo que Marteens dice, en esencia, es:


function GetPropiedad: Tipo;
begin
Calculos; // "muchos" cálculos que determinan FPropiedad
Result := FPropiedad;
end;


Es decir, para determinar el valor de una propiedad se hacen cuantas llamadas a otros métodos sean necesarios para calcular el valor correcto.

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


Mi duda está realmente en el concepto (porque el código, funcioar, funciona). Es decir, en un "sitio" donde recupero un valor... lo cambio también (y antes de devolverlo)... ¿¿??


El problema no está, de hecho, en cambiar el valor de FEstado, en realidad no lo está cambiando- el método SET usado en GET le asigna el que originalmente tenía. La confusión radica en el hecho de estar cambiando el estado del aparato físico desde el método GET. Como Ohcan dice, funcionar, funciona, pero...

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

[marto]

Está claro que el método GET puede alterar las variables internas pero sin embargo mamcx tiene razón.



Pues va a ser que sí :D... yo entendía que simplemente lo que hacía era cambiar el valor de la variable interna, no del teléfono :(. De todas maneras, el primer mensaje de mamcx me sigue pareciendo demasiado tajante al decir JAMAS. Un ejemplo.

Tengo una clase con una propiedad que apunta a otro objeto interno que ocupa un tamaño considerable en memoria. Inicializo la variable a nil y en el Get de la propiedad, si aun vale nil, instancio el obejto. Estoy "alterando el comportamiento/estado interno de un objeto" y creo que es la mejor manera de hacerlo.... ¿no os parece?

[Ohcan]

Hola roman

No estoy de acuerdo contigo en esto

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.
si te estás refiriendo a

Si no son iguales..... tengo 2 opciones:
1. Poner el estado de mi variable = al real
2. al revés, forzar al teléfono a ponerse en el estado que marca la variable.

Verás, el propósito del programa es controlar "al" teléfono (:D) y por eso me decanté por la seguda opción (es decir, en caso de discrepancia de estados, el que manda es el objeto).
Creo que esta decisión no depende de "en qué estemos programando" sino de lo que quiero hacer con la aplicación...
Y al cambiar el estado físico en el Get, me aseguro de que sea el programa el que lleve la voz cantante... además, como tengo que tomar ciertas decisiones fuera del objeto que dependen de su estado, me aseguro de que el teléfono esta "como debe".

[mamcx]

Por eso mismo... nunca digas nunca Jamas! ;)

Bueno pero eso sigue siendo una tarea de lectura... como esperar a leer el Size de un archivo cuando se pregunte... El problema al que apunto (y en base al titulo de este thread) es asignar una tarea de escritura dentro de una de lectura... bueno, es muy confuso... y puede traer efectos laterales posteriormente...

En fin... de todas maneras dentro del contexto de esta discusion creo que quedo claro...

[Ohcan]

Estoy "alterando el comportamiento/estado interno de un objeto"

Creo que realmente no.

Según el título, tal y como dice mamcx, se entiende que hablamos de algo así:

function GetPropiedad:TTipo;
begin
Propiedad := OtroValorDistintoDelQueTieneAhora; //Que llamaría al SetPropiedad
Result := FPropiedad;
end;


Y yo creo que esto último sería incorrecto.

Otra cosa sería, tal y como propones (creo), hacer los cálculos necesarios para hallar el valor ¿no?

[roman]

Verás, el propósito del programa es controlar "al" teléfono (:D) y por eso me decanté por la seguda opción (es decir, en caso de discrepancia de estados, el que manda es el objeto).
Creo que esta decisión no depende de "en qué estemos programando" sino de lo que quiero hacer con la aplicación...
Y al cambiar el estado físico en el Get, me aseguro de que sea el programa el que lleve la voz cantante... además, como tengo que tomar ciertas decisiones fuera del objeto que dependen de su estado, me aseguro de que el teléfono esta "como debe".

¡Pero si yo no he dicho que la segunda opción sea incorrecta! De hecho, basado en lo que describes me parece la más adecuada. Lo "incorrecto", mejor dicho, confuso, es la forma de implementarlo.

// Saludos

[Ohcan]

Lo "incorrecto", mejor dicho, confuso, es la forma de implementarlo.


Cierto roman. Como decía antes, estaba mezclando dos cosas muy distintas.
Y por eso estaba tan liado.

Ahora creo que me ha quedado mucho más claro.
Desde el Set cambio el estado físico del teléfono porque ese es el objetivo real (ahora lo tengo claro) del Set la propiedad y en base a esta premisa....

[marto]

Y yo creo que esto último sería incorrecto.

Pues yo creo que puede ser correcto

Otra cosa sería, tal y como propones (creo), hacer los cálculos necesarios para hallar el valor ¿no?

Vamos a ver... llegamos a un punto en el que la linea que separa una cosa y la otra es muy fina. Cuando dices "hacer los cálculos necesarios para hallar el valor", en el fondo, lo que estás haciendo es cambiar el valor de la variable. Evidentemente, el valor se cambiará en algunos casos y en otros no (porque si no, programa un método, no una propiedad) pero en cualquier caso estas cambiando su valor.
Ejemplo:


constructor TMiClase.Create;
begin
inherited;
FPropiedadCostosa := nil;
end;

function TMiClase.GetPropiedadCostosa: TClaseCostosa;
begin
if not Assigned(FPropiedadCostosa) then
FPropiedadCostosa := TClaseCostosa.Create;
Result := FPropiedadCostosa;
end;

[roman]

marto, ¡qué flojo! :D Esto que describes, que algunos llaman "lazy construction" sigue correspondiendo al modelo:

Calculos;
Result := FPropiedad;

Y los cálculos pueden modificar otras propiedades privadas del objeto, tal como lo hace Marteens por razones de eficiencia básicamente ya que otras propiedades hacen uso de los mismos valores.

Pero aquí se está modificando un aparato externo a fin de cuentas y es lo que es al menos un poco raro. Es algo como:


function TTelefono.Get: TEstado;
begin
Result := FEstado;
DispositivoFisico.Estado := FEstado;
end;


Y es la segunda asignación la que es extraña. En la lógica subyacente se esta escribiendo una propiedad en la lectura de otra (no una variable, una propiedad). Sí, esto es lo que Marteens hace referencia con el principio de Incertidumbre. Y es quizá adecuado para modificar variables internas del objeto a fin de evitar recálculos innecesarios, pero el hecho de que en la física haya tal incertidumbre no significa que debamos, además, crear más incertidumbre en nuestras aplicaciones. :D

// Saludos

[roman]

O dicho de otra forma:


La mamá le dice a Juan:

- Ve a ver si tu hermana está usando el teléfono.

Y Juan va a ver y de paso le cuelga el teléfono a la hermana


:D

// Saludos

[mamcx]

Lo cual me parece muy bien hecho por parte de Juan... a ver si asi hay menos gastos en la cuenta de telefono!

[roman]

Lo cual me parece muy bien hecho por parte de Juan... a ver si asi hay menos gastos en la cuenta de telefono!

Pero en la broma está el punto: Juan se toma atribuciones que no le corresponden, a él sólo le pidieron ver (método GET) si estaba ocupado el teléfono.

Otra cosa hubiera sido si la mamá dice:


- Juan, ¡quiero el teléfono desocupado!

Y va Juan a colgarle el teléfono a la hermana


Ahora Juan hace lo que se le pidió (método SET)

// Saludos

pd: Ojalá todos los días hubiera discusiones tan ricas como ésta en los foros. :)

[Ohcan]

Y siguiendo con el ejemplo, sería en realidad:

- Juan, ¡mira el teléfono, y déjalo como debería estar!

Y Juan 1º se informa de cómo debería estar y 2º, si no está como debiera, lo cambia

:):D;)

[roman]

Y Juan 1º se informa de cómo debería estar y 2º, si no está como debiera, lo cambia


Pero entonces-y me parece qe mamcx ya había mencionado algo al respecto, ya no estamos hablando de una propiedad de un objeto (métodos GET o SET) sino de un método regular. ;)

// Saludos

[Ohcan]

Eso es ...

Realmente la ayuda ha sido muy buena...
y el hilo ha dado mucho mas de sí de lo que hubiera pensado en un principio :)
Sobre todo teniendo en cuenta que al principio pensaba que estaba haciendo una cosa y que al final hago otra :D

Pero... ¡Qué bien viene pensar y razonar!