pregunta tonta sobre "property"

[patroclus02]

Hola a todos,
Aunque llevo varios años desarrollando con Delphi, fui un autodidacta y hay cosas que la verdad no sé si las hago eficientemente.

Por ejemplo, estoy programando un videojuego, con montones de clases y unidades. Cuando defino una clase cualquiera, como esta :

  TEFlyEnemy = class (TEnemy)
  private
    FTopX, FTopY: Integer;        
  public
    property TopX: Integer      read FtopX      write FTopX;
    property TopY: Integer      read FtopY      write FTopY;
    constructor Create(const AParent: TOmegaSprite); override;
    destructor Destroy; override;
    procedure Move(const movecount: single); override;
  end;

No sería mas sencillo en lugar de definir una propiedad Topy, TopX de unos atributos privados FTopX, FTopY, hacer directamente:

  
public
   TopX, TopY: Integer;

Las propiedades tienen sentido si vas a asignar un metodo a la escritura o lectura de la propiedad, pero si simplemente vas a definirla como

    property TopX: Integer      read FtopX      write FTopX;
    property TopY: Integer      read FtopY      write FTopY;

no le veo sentido... en clases muy grandes aumenta aun mas el numero de lineas y se va volviendo confuso de forma inutil.

Me podeis decir algo al respecto?? Espero haberme explicado, gracias!

[dec]

Hola,

Yo le veo cierto sentido, preciamente, en que el código queda más claro haciendo uso de propiedades, a mi entender. Y tiene que ver con el encapsulamiento, con que si sólo declaras variables públicas para que las utilize quien utilize la clase... serán también las que tengas que utilizar tú sin más narices. Y esto puede traerte consecuencias negativas.

Eso es un poco mezclar las cosas, puesto que una cosa es una variable privada y otra una propiedad pública. Tu clase, internamente, debería, en mi opinión, hacer uso de las variables privadas conque contara como miembros. Las propiedades públicas quedan para quien utilize la clase "desde fuera".

Además, en caso de que quisieras cambiar, por ejemplo, como dices, la forma en que se asigna un determinado valor a una propiedad, podrías hacerlo más sencillamente y más claramente si antes diferenciaste entre las variables privadas y las propiedades públicas.

Por ejemplo, quien utilizara tu clase no tendría que variar su código, siempre que el nombre de las propiedades públicas de marras no cambiaran sus identificadores, claro. Sin embargo, tú podrías hacer virgerías dentro de tu clase, desde asignar un método de donde una determinada propiedad tome su valor, hasta combinar varios de ellos, qué sé yo.

En todo caso, insisto: variables privadas, que usará tu clase internamente; propiedades públicas, que utilizarás tú o quien sea fuera de tu clase. No mezclar estas dos cosas creo que es acertado, ahora bien, podéis contradecirme si lo véis menester.

[patroclus02]

si, lo que pasa es que estas clases no van a ser reutilizadas. Son de un videojuego que llevo programando un par de años, y con el que he ido aprendiendo mucho, por lo que si tuviera que hacer algo nuevo, lo haria desde cero, aplicando todo lo que he he aprendido, y haciendo las cosas mejor.
Entiendo perfectamente lo que dices, y la forma es mejor, claro, pero hay variables publicas que no las requiere la clase para nada y que solo se usan externamente por otras clases. Ahi no seria mejor declararla publica y olvidarse de las propiedades??

[dec]

Hola,

No. En mi opinión no sería mejor declarar variables "públicas" con el fin de exponerlas a quien use una determinada clase y además usarlas en el interior de la propia clase. Incluso cuando no pensaras en que las clases van a reutilizarse o algo así. Es lo mismo. Creo que es cuestión de diseño (siempre quise decir algo así).

Ya he dicho antes que, en mi opinión, el propio código fuente sale ganando (tú sales ganando, y quien quiera que tenga que "tocar" dicho código) es más inteligible si las cosas se mantienen en su cauce: variables privadas para uso privado de la clase; y, por otro lado, propiedades públicas para ser usadas desde fuera de la clase.

Lo mismo, por supuesto, con los métodos que contenga una determinada clase. No será muy cabal utilizar métodos públicos desde el interior de una clase, lo mismo que no se permite (o no estará bien, véase más abajo) porque "rompe" con el encapsulamiento que se pretende, digo, utilizar métodos privados de una clase desde fuera de esta.

Piensa por ejemplo en algo peculiar en Delphi. No debería poder accederse a una variable privada desde fuera de una determinada clase en que se encuentre declarada. Pues bien, Delphi, en la unidad donde escribas una determinada clase, fuera de la declaración e implementación de la clase, te permite acceder a las variables privadas de aquélla.

Digo esto para hacerme entender: aunque Delphi te "permite" eso, lo cierto es que no es algo recomendable acceder alegremente a variables privadas de una clase, aunque se pueda, porque estaremos mezclando churras con merinas y eso puede desconcertar a quien estudie nuestro código, traer consecuencias inesperadas, etc., etc.

[[Al González]]

¡Hola a todos!

Quisiera dar mi opinión al respecto, empezando por indicar que el nombre correcto de las mencionadas variables de una clase es campos.

Imaginemos que el nuevo miembro público TopX se declara como campo, y que algún desarrollador (que pudiera ser el mismo autor de esa clase) hace referencia a dicho campo tratándolo como variable:

@Objeto.TopX
ProcGetTop (Objeto.TopX)

Cuando el autor de la clase decida cambiar el campo TopX por propiedad (por el surgimiento de la necesidad de implementarle un método Get de lectura o Set de escritura; o para que pueda ser vista en el inspector de objetos, cambiando su visibilidad a Published; etc.), el código que hace referencia al campo como variable ya no podría compilar y tendría que ser modificado.

Siento que es cuestión de cada caso en particular. Después de todo las reglas y contratos de la POO no son perfectos y les aparecen muchos huecos legales cuando se aterrizan en un lenguaje . En el caso de Patroclus02, quizá baste una leyenda «{ No utilizar estos campos como variables, podrían ser convertidos a propiedades en futuras versiones }», aunque ciertamente la norma general más segura sería declararlos como propiedades.

Un abrazo declarado.

Al González.

[dec]

Hola,

Empezado por Al

Siento que es cuestión de cada caso en particular. Después de todo las reglas y contratos de la POO no son perfectos y les aparecen muchos huecos legales cuando se aterrizan en un lenguaje .

Estamos de acuerdo. Sin embargo, preciasamente, porque la POO está por encima de los lenguajes en particular, no me parece mal seguir sus cánones, si puede decirse así, lo mejor que sepamos y podamos.

Pondré el ejemplo de PHP 4. Esta versión de PHP (la versión 5 ya es harina de otro costal) cuenta con la posibilidad de utilizar clases, empero, sólo pueden declararse variables, no existen las propiedades, y tampoco puede especificarse si un método es público, privado, protegido, etc.

Pues bien. Aunque PHP 4 no permite todo eso, lo cierto es que no es mala cosa tratar de guardar un orden (para lo que ayuda la POO), aunque dicho orden no pueda verse "en el código". Por ejemplo, no debería accederse a una variable de una clase desde fuera de esta.

Eso nos ayuda, entre otras cosas (porque me parece que los beneficios y los perjucios aquí son variados) a portar el código de PHP 4 a PHP 5. No es que sea imposible hacerlo en cualquier otro caso, pero, me temo que el tiempo y el esfuerzo no serían los mismos.

Es decir, tenemos un lenguaje como PHP 4 que, aunque permite en cierto modo programar siguiendo los dictados de la POO (más o menos, no quiero decir que yo sea un gurú del asunto ni de ninguna otra cosa), digo, lo cierto es que no está completamente preparado para este paradigma.

O sea que la POO en PHP 4 no "aterriza" demasiado bien que digamos, y, sin embargo, no es mala cosa seguir sus dictados, tenerlos en cuenta, no mezclar churras con merinas. Claro que cada quien puede hacer lo que quiera, y, además, cada caso particular es es un caso aparte...

[roman]

Empezado por dec

No será muy cabal utilizar métodos públicos desde el interior de una clase

¿Por qué? Si son públicos, son públicos, no importa desde dónde se usen.

Empezado por dec

Piensa por ejemplo en algo peculiar en Delphi. No debería poder accederse a una variable privada desde fuera de una determinada clase en que se encuentre declarada. Pues bien, Delphi, en la unidad donde escribas una determinada clase, fuera de la declaración e implementación de la clase, te permite acceder a las variables privadas de aquélla.

Digo esto para hacerme entender: aunque Delphi te "permite" eso, lo cierto es que no es algo recomendable acceder alegremente a variables privadas de una clase, aunque se pueda, porque estaremos mezclando churras con merinas y eso puede desconcertar a quien estudie nuestro código, traer consecuencias inesperadas, etc., etc.

Yo creo que el hecho de que Delphi te permita acceder a campos privados de una clase desde otra clase en la misma unidad fue algo muy pensado y con razón de ser. Aunque dista de ser perfecto, es lo más cercano a lo que en otros lenguajes se conoce como "clases amigas". Son clases tan compenetradas una con otra, que es permisible que una conozca los interiores de otra sin necesidad de pblicar cosas que a otras clases poco relacionadas no interesarían.

// Saludos