Llamar al Set desde el Get

[[Lepe]]

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

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

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

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

[[Ohcan]]

¡Claro! ¡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...

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

[marto]

Empezado por mamcx

- 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ú no está de acuerdo contigo.... El Principio de Incertidumbre de Heisenberg

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

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