Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > OOP
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Coloboración Paypal con ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 08-10-2006
patroclus02 patroclus02 is offline
Registrado
 
Registrado: oct 2006
Posts: 2
Poder: 0
patroclus02 Va por buen camino
pregunta tonta sobre "property"

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 :

Código:
  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:

Código:
  
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

Código:
    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!
Responder Con Cita
  #2  
Antiguo 08-10-2006
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
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.
__________________
David Esperalta
www.decsoftutils.com

Última edición por dec fecha: 08-10-2006 a las 13:07:35.
Responder Con Cita
  #3  
Antiguo 08-10-2006
patroclus02 patroclus02 is offline
Registrado
 
Registrado: oct 2006
Posts: 2
Poder: 0
patroclus02 Va por buen camino
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??
Responder Con Cita
  #4  
Antiguo 08-10-2006
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
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.
__________________
David Esperalta
www.decsoftutils.com

Última edición por dec fecha: 08-10-2006 a las 13:22:53.
Responder Con Cita
  #5  
Antiguo 09-10-2006
Avatar de Al González
[Al González] Al González is offline
In .pas since 1991
 
Registrado: may 2003
Posts: 5.609
Poder: 30
Al González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en bruto
Smile

¡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.
Responder Con Cita
  #6  
Antiguo 09-10-2006
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Cita:
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...
__________________
David Esperalta
www.decsoftutils.com

Última edición por dec fecha: 09-10-2006 a las 02:10:51.
Responder Con Cita
  #7  
Antiguo 09-10-2006
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Cita:
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.

Cita:
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
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
porque no me reconoce los caracteres "*" ni "%" cuando filtro mrmago Conexión con bases de datos 10 27-01-2006 05:21:16
"Property Does not Exists" en QuickReport Mauro.NET Impresión 3 20-01-2006 20:53:44
Pregunta tonta relacionada con el campo "autoincremento" de paradox ojan69 Conexión con bases de datos 1 20-12-2005 16:43:10
Excepción "Invalid property value" en botón inexistente melanthea C++ Builder 1 07-07-2004 19:12:39
Pregunta MUY tonta sobre querys NeWsP SQL 6 18-01-2004 04:33:10


La franja horaria es GMT +2. Ahora son las 01:07:07.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi