programacion introduccion delphi class record

delphi - programacion - introduccion a pascal



¿Por qué deberíamos usar clases en lugar de registros, o viceversa? (1)

He estado usando Delphi desde hace bastante tiempo, pero en lugar de provenir de un fondo de CS, aprendí "en el trabajo", principalmente de mi Jefe, y aumentado por fragmentos y piezas de la web, guías de usuario, ejemplos. , etc.

Ahora mi jefe es de la vieja escuela, comenzó a programar con Pascal y no se ha actualizado necesariamente con los últimos cambios en Delphi.

Recientemente me he estado preguntando si una de nuestras técnicas principales es "incorrecta".

La mayoría de nuestras aplicaciones interactúan con MySQL. En general, crearemos un record con una estructura para almacenar datos leídos desde la base de datos, y estos registros se almacenarán en una lista de TList . En general, tendremos una unidad que define los diversos registros que tenemos en una aplicación, y las funciones y procedimientos que generan y leen los registros. No utilizamos procedimientos de registro como se describe here

Después de revisar algunos ejemplos, comencé a preguntarme si sería mejor usar classes lugar de registros, pero tengo dificultades para encontrar una guía sólida de cualquier manera.

El tipo de cosa que estamos tratando sería información del usuario: nombres, fecha de nacimiento, eventos, tipos de eventos. O información de la hoja de tiempo: Horas, Trabajos, etc ...


La gran diferencia es que los registros son tipos de valor y las clases son tipos de referencia . En pocas palabras, lo que esto significa es que:

  1. Para un tipo de valor, cuando usa la asignación, a := b , se realiza una copia. Hay dos instancias distintas, b .
  2. Para un tipo de referencia, cuando usa la asignación, a := b , ambas variables se refieren a la misma instancia. Solo hay una instancia.

La principal consecuencia de esto es lo que sucede cuando escribes a.Field := 42 . Para un registro, el tipo de valor, la asignación a. El a.Field cambia el valor del miembro en a , pero no en b . Eso es porque b son instancias diferentes. Pero para una clase, dado que b refieren a la misma instancia, luego, después de ejecutar a.Field := 42 , es seguro afirmar que b.Field = 42 .

No hay una regla estricta y rápida que diga que siempre debe usar tipos de valor, o siempre usar tipos de referencia. Ambos tienen su lugar. En algunas situaciones, será preferible usar una, y en otras situaciones será preferible usar la otra. Esencialmente, la decisión siempre se reduce a una decisión sobre lo que quiere que signifique el operador de asignación.

Usted tiene una base de código existente y, presumiblemente, los programadores que están familiarizados con ella han tomado decisiones particulares. A menos que tenga una razón convincente para cambiar al uso de tipos de referencia, realizar el cambio casi con certeza dará lugar a defectos. Y los defectos tanto en el código existente (cambiar al tipo de referencia cambia el significado del operador de asignación) como en el código que usted escribe en el futuro (usted y sus colegas han desarrollado intuición en cuanto al significado del operador de asignación en contextos específicos, y esa intuición se romperá si cambias).

Además, usted declara que sus tipos no usan métodos. Un tipo que consiste solo en datos, y que no tiene métodos asociados, es muy probable que esté mejor representado por un tipo de valor. No puedo decir eso con seguridad, pero mis instintos me dicen que los desarrolladores originales tomaron la decisión correcta.