Los datos no son comportamiento

1048. Identidad de la lección

Módulo

3.4 — Datos declarativos

Lección

Los datos no son comportamiento

Tipo académico

Concepto

Formato de la lección

Mixto

Orden

Lección 1 del módulo

Tiempo estimado

30–40 minutos, incluida la práctica

Esta lección establece el límite entre la configuración declarativa y las reglas ejecutables. Clasificarás ejemplos como datos, comportamiento o estado; después indicarás quién es responsable de cada elemento y dónde debe validarse su significado.

1049. Objetivo de aprendizaje

Después de esta lección, podrás clasificar un valor o una regla del juego como dato, comportamiento o estado, y justificar tanto su responsable como su límite de validación semántica.

1050. Por qué importa

El código generado puede colocar números ajustables, decisiones ejecutables y hechos temporales de la partida en una misma estructura. Esto dificulta reconocer las responsabilidades. Un cambio de configuración puede alterar un algoritmo de forma inesperada, mientras que un estado mutable puede confundirse con contenido permanente.

Los datos declarativos solo son útiles cuando el sistema define qué significa cada valor, quién se responsabiliza de su esquema y cuáles son los valores aceptables. Una clasificación clara ayuda a revisar implementaciones generadas y detectar acoplamientos accidentales.

1051. Conocimientos previos

Debes poder identificar dependencias directas y eventos, distinguir una operación con responsable de un hecho difundido y explicar por qué una comunicación descontrolada mediante eventos produce una red de interacciones difícil de entender. Estas ideas se presentaron en 3.3 L2 — Evitar una maraña de eventos. También debes saber leer campos, tablas y reglas condicionales sencillas.

1052. Concepto central

Los datos describen opciones o parámetros; el comportamiento toma o ejecuta decisiones; el estado registra lo que es cierto ahora.

Los datos declarativos forman una descripción que un sistema consume sin sustituir el algoritmo que la interpreta. Algunos ejemplos son el precio de un objeto, el alcance máximo configurado de un arma o una duración de reutilización. Estos valores siguen necesitando un esquema definido y límites con sentido.

El comportamiento es lógica ejecutable: condiciones, cálculos, transiciones, procedimientos y efectos secundarios. «Si el objetivo está fuera del alcance configurado, rechazar la acción» es comportamiento. El alcance utilizado por la regla puede ser un dato, pero la comparación y el rechazo son comportamiento.

El estado es información que cambia mientras se ejecuta el juego. La salud actual, si la interfaz de diálogo está abierta en este momento y el tiempo restante para volver a usar una acción son estados. Un diseñador puede configurar la salud máxima o la duración de reutilización, pero los valores actuales pertenecen a un responsable durante la ejecución.

La clasificación depende del papel y del contexto, no de la sintaxis. Un número almacenado en un archivo no es automáticamente configuración, y un número escrito en el código no es automáticamente comportamiento.

Una distinción para los valores controlados por el código

Una constante de implementación no es una cuarta clasificación principal. Es un valor controlado por el código dentro de la clasificación general de datos o valores. Por ejemplo, MAX_SERIALIZED_ITEMS = 256 puede expresar un contrato de implementación en vez de una opción de ajuste creada por un diseñador. La constante sigue siendo un valor; el código que compara una cantidad con ella es comportamiento.

Un campo también puede ocultar instrucciones ejecutables. Si un sistema evalúa onUse = "applyDamage(); startTimer();", el texto se almacena como dato, pero se utiliza como comportamiento. El formato de almacenamiento no convierte esa responsabilidad en declarativa.

1053. Modelo mental: Describir–Decidir–Registrar

Aplica esta prueba de clasificación:

1. Si una persona responsable del contenido cambia un valor sin pretender alterar el algoritmo que lo interpreta, clasifícalo como dato de configuración.
2. Si el código controla un parámetro fijo exigido por un contrato de implementación, clasifícalo como valor de datos controlado por el código, normalmente llamado constante de implementación.
3. Si un elemento expresa una decisión, transición, cálculo, procedimiento o efecto secundario, clasifícalo como comportamiento.
4. Si un valor cambia durante la partida para representar la situación actual, clasifícalo como estado.
5. Si falta contexto, indica el supuesto antes de clasificar. Distintas respuestas pueden ser defendibles si parten de responsables o ciclos de vida diferentes.
6. Si un campo cumple varias funciones a la vez, sepáralo en representaciones distintas para datos, comportamiento y estado.

La validación debe situarse en el límite por el que una responsabilidad entra en su sistema responsable. El cargador de configuración valida los valores creados, el responsable de una operación protege sus reglas y el responsable durante la ejecución conserva las invariantes del estado.

1054. Ejemplo concreto

Considera un objeto consumible con un retraso de reutilización configurado en tres segundos:

Datos del objeto creados por diseño:
  reuseDurationSeconds = 3.0

Comportamiento del sistema de uso de objetos:
  cuando se solicita Use:
    si reuseRemainingSeconds > 0, rechazar la solicitud
    en caso contrario, aplicar el efecto e iniciar el temporizador

Estado de una instancia durante la ejecución:
  reuseRemainingSeconds = 1.7

La duración es un dato porque describe contenido ajustable. Su esquema debe rechazar valores situados fuera del rango documentado. La comprobación de la solicitud, la aplicación del efecto y la actualización del temporizador son comportamiento del sistema de uso de objetos. El tiempo restante es estado porque registra la condición actual de una instancia concreta.

Colocar un campo mutable canUse en una configuración compartida mezclaría configuración y estado. Varias instancias podrían compartir un indicador temporal, o un hecho propio de una sesión podría guardarse como contenido permanente.

1055. Errores frecuentes

Un error consiste en tratar todo lo almacenado en un archivo de datos como declarativo. Un campo mutable currentHealth pertenece al estado de ejecución aunque se haya serializado, mientras que una expresión de código guardada como texto sigue siendo comportamiento ejecutable si el sistema la evalúa.

Otro error es comprobar únicamente la sintaxis. Un valor puede ser numérico y, aun así, resultar inválido por su significado. Algunos ejemplos son un coste negativo, una probabilidad fuera del rango documentado o una duración de reutilización que incumple el contrato del sistema. La validación debe comprobar significados, referencias, rangos y, cuando corresponda, reglas entre varios campos.

Un tercer error es clasificar un campo ambiguo sin describir su contexto. dialogueOpen = true podría ser un valor inicial configurado o el estado actual del sistema de diálogo. La responsabilidad y el ciclo de vida determinan la respuesta.

1056. Práctica guiada

Clasifica cada elemento contextualizado como dato, comportamiento o estado. Después indica su responsable probable y una cuestión de validación semántica.

1. Un ajuste de capacidad de carga creado por diseño: maximumCarryWeight = 30.
2. La carga actual medida en una instancia del inventario: currentCarryWeight = 18.
3. La regla ejecutable del sistema de recogida: if currentCarryWeight + itemWeight > maximumCarryWeight, reject pickup.
4. El indicador actual de la interfaz en el sistema de diálogo durante la ejecución: dialogueOpen = true.
5. Una tabla de recompensas creada como contenido: rewardTable = [{ item: "medkit", chance: 0.25 }].
6. La operación de recogida: «Cuando se acepte una recogida, añadir el objeto al inventario y emitir PickupAccepted».

Para el elemento 5, decide también si las probabilidades deben sumar exactamente 1.0, si pueden sumar menos de 1.0 dejando implícito el resultado «nada» o si deben seguir otra regla documentada. No existe una elección universal: el esquema de la tabla de recompensas debe declarar y aplicar su contrato.

Clasificaciones sugeridas:

• 1 — Dato: su responsable es el esquema de configuración de la capacidad de carga; debe validarse que sea finito, no negativo y compatible con el rango de diseño documentado.
• 2 — Estado: su responsable es el inventario durante la ejecución; debe mantenerse coherente con el contenido del inventario y no volverse negativo.
• 3 — Comportamiento: su responsable es la operación de recogida o inventario; hay que comprobar la comparación y garantizar que un rechazo no produzca efectos propios de una aceptación.
• 4 — Estado: su responsable es el sistema de diálogo durante la ejecución; sus transiciones deben actualizarlo mediante el controlador de interfaz correspondiente.
• 5 — Dato: su responsable es el esquema de recompensas; deben validarse las referencias a objetos, los límites de probabilidad y la regla documentada sobre el total.
• 6 — Comportamiento: su responsable es la operación de recogida; deben conservarse el orden y el contrato de la modificación del inventario y de la emisión del evento.

Si el elemento 1 representara en cambio un límite estricto de implementación, seguiría siendo un valor de datos, pero su responsable sería el módulo de código y no el esquema de contenido. Si el elemento 4 representara una condición inicial configurada de la interfaz, sería un dato de configuración. Cuando el contexto no establezca el ciclo de vida, indica siempre tu supuesto.

1057. Evaluación práctica

Completa la evaluación práctica vinculada. Clasificarás un valor configurado, una regla ejecutable y un valor de ejecución. Para cada uno, tendrás que indicar su responsable y una cuestión de validación semántica. Esta actividad evalúa un razonamiento que el cuestionario de reconocimiento no puede comprobar por sí solo.

1058. Evidencia de aprendizaje

Tu clasificación está fundamentada cuando puedes explicar:

• qué representa el elemento dentro del contexto indicado;
• por qué es dato, comportamiento o estado;
• qué esquema, sistema, módulo o entidad es responsable;
• qué condición semántica debe comprobarse en el límite de ese responsable.

Cuando el contexto sea insuficiente, identifica el supuesto que falta en lugar de presentar una clasificación incondicional.

1059. Ideas clave

• Los datos describen valores; el comportamiento ejecuta decisiones y efectos; el estado registra hechos actuales de la ejecución.
• Una constante de implementación es un valor de datos controlado por el código, no una cuarta clasificación principal.
• El contexto, la responsabilidad y el ciclo de vida determinan la clasificación; no lo hacen el formato ni la sintaxis.
• La validación debe comprobar restricciones semánticas, no solo tipos.
• Mantén la configuración separada del estado mutable de cada instancia.
• Conserva las decisiones ejecutables en el sistema responsable de la operación.

1060. Siguiente lección

A continuación, continúa con 3.4 L2 — Convertir una regla ajustable en declarativa, donde representarás una regla ajustable como datos explícitos con un esquema y un límite de validación definidos.

1061. Comprobación