Llamar al Set desde el Get

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

Empezado por Ohcan

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

Empezado por Ohcan

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]

Empezado por roman

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

[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]]

Empezado por marto

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

Código Delphi [-]
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?

[marto]

Empezado por Ohcan

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

Pues yo creo que puede ser correcto

Empezado por Ohcan

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:

Código Delphi [-]
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! 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.

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

// Saludos

[[Ohcan]]

Hola roman

No estoy de acuerdo contigo en esto

Empezado por roman

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

Empezado por Ohcan

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 () 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".

[roman]

Empezado por Ohcan

Verás, el propósito del programa es controlar "al" teléfono () 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]]

Empezado por roman

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