Ocultar propiedades de la herencia

[elcolo83]

Hola a todos... quiesiera saber como puedo ocultar algunas propiedades de la herencia. El tema es que estoy haciendo un componente derivado del TListBox y quisiera que por ejemplo "itmes" no lo vea el programador ya que lo administra el mismo componente... de esa forma evique que me agreguen items a la lista... como se hace????

[[maeyanes]]

Hola...

Desgraciadamente no se pueden ocultar propiedades públicas en clases heredadas...

O mejor dicho, no se puede bajar el nivel de visibilidad de una propiedad o método en una clase heredada... esto es, si una propiedad es públished en una clase, no la puedes declarar como protected en una clase descendiente...

La opción que tienes es checar si la clase padre de TListBox tiene la propiedad Items declarada como protected y heredes desde esa clase...


Saludos...

[elcolo83]

gracias por tu respuesta maeyanes.... estaba pensando... y cambiar o sobreescribir las funciones add y delete de la propiedad items??? tampoco se puede?

[[maeyanes]]

Hola...

El detalle es que los métodos Add y Delete pertenecen a la clase TStrings de la cual proviene la propiedad Items, por lo que no puedes redefinirlos desde la clase heredada de TListBox...


Saludos...

[elcolo83]

Muchas gracias por aclararme las dudas...

Saludos

[[basti]]

En vez de heredar de TListBox, puedes heredar de TCustomListBox. Las clases TCustomXxxx son las mismas que sus correspondientes sin el custom. La diferencia está en que las propiedades no son públicas. Las que te interese hacer públicas las puedes declarar en la sección Published.

[[Al González]]

¡Hola!

Empezado por basti

...En vez de heredar de TListBox, puedes heredar de TCustomListBox. Las clases TCustomXxxx son las mismas que sus correspondientes sin el custom. La diferencia está en que las propiedades no son públicas. Las que te interese hacer públicas las puedes declarar en la sección Published.

En realidad sí son públicas (Public) en muchos casos. TCustomListBox.Items es una propiedad pública, pero no publicada. Existe una diferencia importante entre un término y el otro.

Una sección Public declara elementos públicos que pueden ser accedidos desde cualquier lugar del código.

Una sección Published declara elementos públicos publicados, es decir, que además de ser públicos pueden ser accedidos por los mecanismos del IDE en tiempo de diseño (como el inspector de objetos) y guardar sus valores en un DFM.

Por el requerimiento del caso, al igual que maeyanes y basti, aconsejo derivar la nueva clase de TCustomListBox.

Me sorprende la cantidad de gente que ya le está entrando a la POO de componentes Delphi derivados. Me pregunto si los programadores asiduos a otros lenguajes gozarán de esta misma capacidad y libertad, además del interés por crear sus propias clases de objetos. Son muchos los que por fin se animan a sacarle más provecho a la enorme potencia de Delphi. Enhorabuena elcolo83.

Un abrazo custom.

Al González.

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

En realidad sí hay un pequeño truco o "chapucilla" para ocultar en el inspector de Objetos propiedades published de componentes que están por "encima" en la herencia.
Lo hemos discutido alguna vez, por ejemplo aquí.

Otra cosa es que te plantees si es correcto o no. Es decir, que si a un componente A que deriva de otro B, debes ocultarle propiedades, tal vez sea porque A no deberia derivar de B (sólo piénsalo antes de continuar).
De todas formas si la herencia es correcta, y te sigue interesando hacerlo, puedes usarlo, funciona bien.

[elcolo83]

Anda bien lo que decis neftali para ocultar las propiedades (eso no es poliformismo? o es otra cosa?) el unico problema es que ni si quiera yo dentro del mismo componente tengo acceso a Items cuando uso eso...

[[maeyanes]]

Hola...

No es poliformismo, el poliformismo es otra cosa... Lo que te comenta Neftali es solo una técnica...


Puedes usar la propiedad de la clase padre tal como:

Código Delphi [-]
begin
  inherited Items[0] := 'Un valor';
end;

Saludos...

[elcolo83]

Perdon... cuando me referia a poliformismo me referia a este codigo

Código Delphi [-]
type
  // Tipo Dummy
  TDummyProp = (dummyprop);
  // definición del componente derivado
  tcomboBoxNew = class(tcombobox)
  private
    { Private declarations }
    _DummyProp: TDummyProp;
  protected
    { Protected declarations }
  public
    { Public declarations }
  published
    { Published declarations }
    // Ocultar propiedades ============================
    property Charcase:TDummyProp read _DummyProp;
    property Color:TDummyProp read _DummyProp;
    property Constraints:TDummyProp read _DummyProp;
    property Ctl3D:TDummyProp read _DummyProp;
    property Cursor:TDummyProp read _DummyProp;
  end;

que esta en el link que envio neftali.... lo que se hace en este codigo.... es poliformismo???

[[maeyanes]]

Nop...

Es solo herencia de clases...

La parte de "ocultar" las propiedades es solo una técnica y hace uso de una característica de Delphi de poder modificar la forma en como se escribe o lee una propiedad en clases descendientes...



Saludos...

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

Empezado por elcolo83

...el unico problema es que ni si quiera yo dentro del mismo componente tengo acceso a Items cuando uso eso...

En ese caso debes utilizar la versión heredada, que no ha sido modificada.
Si en tu componente has utilizado el Dummy con la propiedad Caption, por decir algo, para modificarla dentro de tu componente debes utilizar:

Código Delphi [-]
  inherited Caption := 'Modificando el valor...';

[elcolo83]

Les agradezco a todos por el interes en el tema; pude hacer lo que queria.... lo que hice fua plicarle el Dummy a la propiedad items del componente heredado de un TListBox (dentro del componente se modifica usando el inherited como deijo neftali) y luego redefini la funcion additems para que no haga nada cuando esta es invocada...

Ademas de solucionarme el problema me explicaron algunas cosas que no tenia muy en claro asi una vez mas se los agradezco... y agregando un poco a lo que decia "Al Gonzalez", creo que Delphi es imprecionante a la hora de manejar la OOP y solo lo limita la imaginacion de quien programe en este sorprendente lenguaje... como decia mi profesor de informatica: "usen la imaginacion, del resto se encarga el compilador".

[[Delphius]]

Se que ya sea comentado al respecto y se ha dado una posible solución. Esta es la 4ta o 5ta vez que leo el hilo y sigue habiendo algo que no me queda claro.

Empezado por elcolo83

Hola a todos... quiesiera saber como puedo ocultar algunas propiedades de la herencia. El tema es que estoy haciendo un componente derivado del TListBox y quisiera que por ejemplo "itmes" no lo vea el programador ya que lo administra el mismo componente... de esa forma evique que me agreguen items a la lista... como se hace????

El ListBox está para ello para agregar, eliminar items. Es su FUNCION y propósito como objeto. ¿Que finalidad tiene derivar de él si no se desea contar con el propósito con el que ha sido diseñado?
Esto va por lo que ya Neftali recalcó:

Empezado por Neftali

Otra cosa es que te plantees si es correcto o no. Es decir, que si a un componente A que deriva de otro B, debes ocultarle propiedades, tal vez sea porque A no deberia derivar de B (sólo piénsalo antes de continuar).

Es cierto que como dice muchos que el TCustomListBox ofrece una buena alternativa... Al menos para mi, y teniendo como punto de partida la simple descripción del problema, me resultaría más práctico y ventajoso emplear un descendiente de TCustomListBox. Es la mejor clase candidata.

Considero que elcolo83 nos explicase mejor su situación. Con haber dicho esas cortas frases no somos capaces de saber si es realmente beneficioso que implemente dicho truco ¿Cúal es el verdadero objetivo que te planteas elcolo83?

El diseño de nuevos componentes que sirvan para propósitos generales no es una actividad que pueda tomarse a la ligera... Considero, y casi siempre hago llamar la atención, a que se haga un mejor y profundo análisis antes de optar por alguna alternativa.

Al comienzo, en las primeras lecturas que hice del hilo, estuve pensando que se trata de un caso de Adaptador... que la clase oculte el comportamiento de un TListBox pero.... ahora decanto que sea ventajoso una alternativa como ésta. Sobre todo por el hecho de que me hice una simple pregunta ¿Y de que clase debe heredar el Adaptador? Al menos de lo que yo comprendo sobre el patrón adaptador se puede conseguir de estas formas:

1. Con la herencia:

Código Delphi [-]
TAdaptador = class(TAdaptado);
....
end;

TAdaptador.HacerCosa(Algo: TAlgo);
begin
   inherithed HacerCosa;
end;

2. Con el encapsulamiento:

Código Delphi [-]
TAdaptador = class(????);
private
   Adaptado: TListBox; 
   { No lo mostramos.... el usuario de la clase no tiene porque saber
     que internamente posee un TListBox y éste hará lo que deba hacer }
end;

TAdaptador.HacerAlgoUnPocoDistintoACosa(Algo: TipoAlgo);
begin
  .... 
  Adaptado.HacerCosa(Algo);
  ...
end;

Hay algo que no me ha dejado tranquilo y siento que algo se me escapa...
Me gustaría que alguien me explicase que finalidad tendría hacer algo como lo del truco. Yo siento que se trata de un error de diseño (o mejor dicho de una comprensión erronea del dominio).

Sabemos que el mundo POO está impregnado de la subjetividad (y personamlente es eso lo que lo hace grandioso, desafiante e interesante) pero me encantaría que tanto elcolo83 como los demás que han participado del hilo compartan su comprensión del tema aqui expuesto.

Saludos,

[[basti]]

Me permito contestarte alguna de tus cuestiones:

Empezado por Delphius

El ListBox está para ello para agregar, eliminar items. Es su FUNCION y propósito como objeto. ¿Que finalidad tiene derivar de él si no se desea contar con el propósito con el que ha sido diseñado?

En la paleta Additional hay un componente llamado TColorBox (no es un listbox pero sí un combo), ahí hay un caso en el que no tiene sentido modificar los items de de la lista.

Empezado por Delphius

Es cierto que como dice muchos que el TCustomListBox ofrece una buena alternativa... Al menos para mi, y teniendo como punto de partida la simple descripción del problema, me resultaría más práctico y ventajoso emplear un descendiente de TCustomListBox. Es la mejor clase candidata.

En eso coincidimos, fue la primera posible solución que planteé, de hecho el componente que menciono antes hereda de TCustomColorBox, que a su vez hereda de TCustomComboBox.

Empezado por Delphius

El diseño de nuevos componentes que sirvan para propósitos generales no es una actividad que pueda tomarse a la ligera... Considero, y casi siempre hago llamar la atención, a que se haga un mejor y profundo análisis antes de optar por alguna alternativa.

No creo que el diseño de componentes tenga que ser únicamente con propósitos generales. Puede ser un componente muy específico que se utilice varias veces en una misma aplicación. Se me ocurren muchos ejemplos en este caso. Una lista que adquiere los datos a través de sockets o de un puerto serie, de una base de datos, de un archivo, del registro de windows, del sistema de archivos...

Empezado por Delphius

Hay algo que no me ha dejado tranquilo y siento que algo se me escapa...
Me gustaría que alguien me explicase que finalidad tendría hacer algo como lo del truco. Yo siento que se trata de un error de diseño (o mejor dicho de una comprensión erronea del dominio).

Yo tampoco usaría este truco para este caso, sólo lo usaría en caso de que no existiese una clase TCustomXXXX para un componente. Sin embargo, como bien dices, lo bueno de Delphi es que nos permite varias alternativas para este (y otros muchos casos). Creo que si elcolo83 se decidió por esa opción es porque la vio más clara.

[[Delphius]]

Muchas gracias basti por responder a mis dudas.

Espero que los demás también pudiera exponer su punto de vista, sobre todo que elcolo83 pudiera explicar el propósito de su solución. No es que esté criticando la manera en que trabaja sino que todavía me siento intranquilo con el tema. Reconozco que esto me ha llamado la atención y me gustaría conocer con mayores detalles lo que pretende elcolo83.

Es que con decir esas únicas líneas, a mi no me bastaría, para optar por dicha solución... ¿Hay otros motivos que podrían tomarse en cuenta?

elcolo83 no quiero iniciar problemas... sólo es que al estar acostumbrado a pensar demasiado en el enfoque tradicional de POO me hace sentir que ocultar un comportamiento heredado tal como lo planteas escapa a los conceptos que tengo.

Me entaría, si se puede y no te es una molestia, que explicaras y profundizaras sobre el tema. Creo que puede hallarse otras alternativas que podrías tomar en cuenta.

Saludos,

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

Empezado por Delphius

Me gustaría que alguien me explicase que finalidad tendría hacer algo como lo del truco.

Hola Delphius.
En mi caso, y como ya he dicho alguna vez, no tiene nada que ver con la POO. Alguna vez he utilizado esta técnica por simple comodidad.

Diseñamos componentes que luego utilizamos y hay muchas propiedades que por temas de simplicidad y por temas de estandarización nos interesa fijar y ocultar (para que no se modifiquen). Esta también es una buena opción para "Limpiar" la visión del inspector de objetos.

[elcolo83]

Hola a todos, pido mil disculpas por mi ausencia, lo que paso es que estaba de vacaciones y sinceramente no he tocado una pc en una semana...
Bueno, les paso a explicar cual es la finalidad de mi componente para ver si se entiende que es lo que quise hacer (que de hecho gracias a la ayuda de muchos de ustedes logre)...
El tema es que estoy haciendo una aplicacion que entre otras cosas lo que hace es guardar varios archivos (propios de la aplicacion) en un solo archivo, o sea varios TFlieStreams en uno solo y lo guardo con una extecion ".cont" (contenedor). Lo que hace mi nuevo TListBox es mostrarme el contenido del ".cont", y darme la posibilidad de extraer o agregar un archivo nuevo al punto "cont.". Es por eso que no queria que se agreguen item asi porque si ya que el componente podria mostrar un contenido que no es real... A este componente le agregue la funcion "AddItem" que lo que hace es agregar un archivo al ".cont" y mostrar nuevamente el contedido de este (por lo que aparecera un nuevo item) tambien le agregue una funcion llamada "GetItem" cuyo parámetro es el index al cual se quiere acceder y esta devuelve el nombre del archivo/item que esta en esa pocicion de la lista.
No se si soy demaciado claro con esta explicacion... si no es asi por favor pregunten lo que sea necesario para aclarar el tema.

Saludos...