Crear una hoja de ownership de estado

1003. Identidad de la lección

Módulo

3.2 — Estado global y local

Lección

Crear una hoja de ownership de estado

Tipo académico

Práctica guiada

Tipo de esquema

práctica

Orden

Lección 2 del módulo

Tiempo estimado

45–60 minutos, incluida la práctica

Esta lección convierte la diferencia entre scope y ownership en un artefacto auditable. Crearás una hoja de ownership de estado y la usarás para identificar una variable compartida insegura o sin resolver.

1004. Objetivo de aprendizaje

Al terminar esta lección, podrás producir una hoja de ownership de estado que indique el sistema con autoridad de escritura, los lectores y la operación de escritura permitida para cada valor resuelto, y después identificar y justificar una variable compartida insegura o sin resolver.

1005. Por qué importa

Que varios sistemas puedan ver un valor no significa que todos deban modificarlo. Cuando las responsabilidades quedan implícitas, un componente de interfaz, un controlador, una rutina de guardado y una regla de juego pueden escribir el mismo valor por motivos distintos. El defecto resultante suele ser un desacuerdo sobre la autoridad, no un error de sintaxis.

Una hoja de ownership hace que ese desacuerdo pueda inspeccionarse. Sirve para orientar la asistencia de la IA, revisar código y decidir dónde debe validarse y confirmarse un cambio de estado.

1006. Conocimientos previos

Debes poder distinguir scope de ownership, como se explicó en 3.2 L1 — Scope is not ownership. También debes poder describir la responsabilidad de un sistema e identificar el estado que lee sin suponer que posee las reglas correspondientes.

1007. Concepto central

Una hoja de ownership de estado registra decisiones separadas para cada valor importante:

1. Valor de estado: ¿Qué hecho o valor existe?
2. Sistema con autoridad de escritura: ¿Qué sistema posee la regla que valida y confirma los cambios?
3. Lectores: ¿Qué sistemas pueden observar, serializar o mostrar el valor?
4. Límite de cambio permitido: ¿Qué operación con autoridad puede confirmar el cambio? Si el diseño utiliza solicitudes, ¿qué solicitud se acepta y qué operación realiza el cambio definitivo?
5. Evidencia o duda: ¿Qué código, regla o pregunta pendiente respalda la clasificación?

Una solicitud no equivale a un cambio confirmado. Un comando puede solicitar una transición, una operación con autoridad puede validarla y confirmarla, y un evento puede avisar a otros sistemas de que un hecho ha cambiado. No des por sentado que todos los eventos escriben estado.

En esta hoja, registra una de estas opciones:

• la operación con autoridad que confirma el cambio, como applyDamage(amount); o
• tanto la solicitud aceptada como la operación que confirma el cambio, por ejemplo RequestDamage(amount) → HealthSystem.applyDamage(amount).

El diseño detallado de contratos de mensajes corresponde al Módulo 3.3. Aquí el objetivo es hacer explícito el límite de ownership.

1008. Modelo mental

Usa el modelo una autoridad, muchos lectores:

solicitud ─────────▶ sistema con autoridad ─────────▶ estado confirmado
                     valida y confirma
                              │
                ┌─────────────┼─────────────┐
                ▼             ▼             ▼
             lector HUD   lector guardado  otro lector
                              │
                    notificación del cambio

Para cada fila, responde estas preguntas en orden:

Una variable merece revisión cuando tiene escritores no relacionados, cuando un lector escribe por comodidad, cuando la restauración se salta al sistema responsable o cuando no existe un límite de confirmación explícito.

1009. Ejemplo concreto

Lo importante es el límite de responsabilidad, no el nombre de la variable. Otros sistemas pueden solicitar u observar un cambio, pero el sistema responsable decide si es válido y lo confirma. Una notificación emitida después puede informar a los lectores sin convertirse en otro escritor.

Si una fila parece tener dos sistemas independientes con autoridad de escritura, no aceptes la situación sin más. Marca la fila para revisarla, documenta por qué la autoridad dividida es intencional o registra la evidencia necesaria para resolver la duda.

1010. Estado guardado y restaurado

La serialización suele leer el estado, pero la restauración puede escribirlo. Para cada valor guardado o restaurado, identifica:

• el sistema que lee el valor para serializarlo;
• el sistema que valida los datos restaurados; y
• la operación con autoridad que confirma el valor restaurado.

Señala cualquier escritura directa del deserializador que se salte el sistema responsable de la regla. Por ejemplo, un cargador puede entregar los datos de desbloqueos restaurados, pero el sistema de progresión debería validarlos y confirmarlos si posee las reglas de desbloqueo.

1011. Flujo de trabajo con IA

Usa la IA como asistente de clasificación y revisión, no como responsable de la decisión de diseño.

1. Redacta la hoja a partir de las responsabilidades de los sistemas y de la evidencia del código que puedas identificar.
2. Pide a la IA que encuentre filas con varios posibles escritores, lectores que parezcan mutar el estado, límites de cambio vagos o rutas de restauración que se salten al sistema responsable.
3. Pídele que explique cada duda usando los campos de la hoja. No le pidas que rediseñe automáticamente la arquitectura.
4. Compara cada sugerencia con las reglas del juego y la evidencia disponible.
5. Acepta, rechaza o modifica cada sugerencia de forma explícita.
6. Selecciona una variable compartida insegura o sin resolver y documenta la evidencia que respalda tu conclusión.

Puedes usar esta instrucción:

Revisa esta hoja de ownership de estado. Para cada fila, distingue el sistema con autoridad de escritura de los lectores. Señala varios escritores, operaciones de confirmación vagas, lectores que muten el estado y rutas de restauración que se salten al responsable. No rediseñes los sistemas. Explica la evidencia de cada señalamiento y conserva las incógnitas explícitas.

Si el proyecto no ofrece información suficiente para clasificar una fila, escribe desconocido en lugar de adivinar. Una brecha de evidencia explícita es más útil que una asignación segura pero infundada.

1012. Errores frecuentes

Confundir almacenamiento con ownership

El componente que almacena una variable no es automáticamente la autoridad para cambiarla. La ubicación del almacenamiento, el scope de acceso y el ownership son decisiones distintas.

Llamar escritor a todo solicitante

Un sistema que envía una solicitud no es necesariamente el sistema que confirma el cambio. Registra ambos pasos cuando la distinción sea relevante.

Tratar las notificaciones como escrituras

Un evento puede anunciar un cambio que ya ocurrió. No lo registres como operación de escritura a menos que la arquitectura lo utilice expresamente como solicitud aceptada y también identifique la operación que valida y confirma el estado.

Ignorar la restauración

Un cargador que asigna valores directamente puede saltarse la validación. Registra quién valida y confirma los datos restaurados en lugar de tratar la carga como una simple lectura.

1013. Práctica guiada

Crea una hoja de ownership para una parte pequeña de un juego que conozcas. No cambies el código del proyecto durante este ejercicio. Usa esta estructura:

Completa al menos seis filas e incluye:

• un valor de estado del jugador o de un actor;
• un valor visible en la interfaz;
• un valor de progresión o desbloqueo;
• un valor temporal de la sesión;
• un valor guardado o restaurado; y
• un valor cuya autoridad no esté clara.

En la fila del valor guardado o restaurado, indica quién valida y confirma la restauración. Señala la fila si un deserializador escribe directamente y se salta al sistema con autoridad.

Después audita la hoja:

1. Marca cada fila con más de un posible escritor.
2. Comprueba si algún lector también muta el valor.
3. Sustituye permisos vagos como “puede actualizarlo” por una operación con autoridad o por una ruta que muestre la solicitud y la confirmación.
4. Comprueba que las filas resueltas distingan solicitudes, confirmaciones y notificaciones cuando sea necesario.
5. Selecciona una variable compartida insegura o sin resolver.
6. Escribe un diagnóstico de dos frases que nombre los escritores en conflicto y la autoridad preferida, o que describa la evidencia que falta y la siguiente inspección necesaria.

Tu decisión de diseño consiste en seleccionar y justificar la variable insegura o sin resolver. No fuerces una asignación de autoridad cuando no haya evidencia suficiente.

1014. Punto de control práctico

Entrega la hoja terminada y el diagnóstico mediante Auditoría de una hoja de ownership de estado, la evaluación práctica asociada a esta lección. Se comprobará que las seis filas identifiquen autoridades o brechas de evidencia, separen los lectores, nombren límites de cambio válidos, aborden la restauración y justifiquen una variable insegura o sin resolver.

1015. Validación y evidencias

1016. Ideas clave

• El scope describe quién puede acceder al estado; el ownership indica quién valida y confirma los cambios regidos por sus reglas.
• Un sistema con autoridad de escritura y muchos lectores es un buen punto de partida.
• Una solicitud pide una transición; la operación con autoridad la valida y confirma; una notificación puede anunciar el resultado.
• La restauración debe pasar por una autoridad documentada en lugar de saltarse al sistema responsable.
• Varios escritores no relacionados indican un límite inseguro o sin documentar.
• La IA puede señalar inconsistencias, pero la decisión sobre el ownership sigue siendo tu responsabilidad.

1017. Siguiente lección

A continuación: 3.3 L1 — Un mensaje es un contrato. La información sobre el productor, la autoridad, la solicitud permitida y la operación de confirmación de tu hoja te ayudará a redactar un contrato de evento completo sin confundir una solicitud, un cambio de estado confirmado y su notificación.

1018. Comprobación