# Programación orientada a datos La programación orientada a datos es un enfoque poderoso para programar que produce grandes mejoras en el rendimiento. Se centra en tratar *los datos* como el elemento central; todo lo demás se organiza a su alrededor, ya sea para acceder a esos datos o modificarlos. Este enfoque también es muy amigable para Multiplayer, ya que hace que los datos que necesitan sincronizarse entre jugadores sean más fáciles y rápidos de acceder. La programación orientada a datos te anima a pensar en todo en tu scene como datos que deben copiarse y mutarse a través de los distintos systems. El principal beneficio de este enfoque está en optimizar la velocidad a la que los datos pueden leerse desde la memoria, que a menudo es el principal cuello de botella al ejecutar aplicaciones y juegos modernos. Debido a esta notable mejora en el rendimiento, gran parte de la industria de desarrollo de juegos se ha estado orientando hacia la adopción de este enfoque en los últimos años. El SDK de Decentraland ejecuta scenes en JavaScript, y uno de los inconvenientes de este lenguaje es que no ofrece control sobre la asignación de memoria. El engine que ejecuta Decentraland, sin embargo, usa C#, que sí se beneficia mucho al seguir principios orientados a datos. El SDK y el engine se están enviando mensajes constantemente entre sí. Para que esta comunicación sea lo más eficiente posible, tiene sentido mantener las estructuras de datos en ambos lados lo más similares posible, para evitar tener que reorganizar estos datos constantemente. ## Cómo se ve La programación orientada a datos es diferente de la programación orientada a objetos, un enfoque con el que muchos developers están familiarizados actualmente. En la programación orientada a objetos, el code se estructura siguiendo abstracciones que intentan replicar construcciones del mundo real: objetos. Cada uno de estos objetos puede contener tanto datos como funcionalidad. Las aplicaciones que usan este enfoque suelen ser fáciles de planificar conceptualmente, pero también más ineficientes al ejecutarse. En la programación orientada a datos, los datos no se estructuran alrededor de objetos; se estructuran para optimizar su facilidad de acceso. Las construcciones del mundo real que representan los datos no influyen en los distintos flujos que mutan esos datos. El modelo Entity Component System (ECS) en el que se basa el SDK de Decentraland es muy compatible con el enfoque de programación orientada a datos. Cada component es parte de una colección estructurada de datos. Los components pertenecen a una entity por referencia, pero los datos no se estructuran alrededor de la entity; los datos se estructuran como una colección de components similares. Por ejemplo, todos `Transform` los components en una scene son iguales. Uno de estos transforms podría pertenecer al modelo de tu edificio principal, otro a un vaso que es hijo de una mesa. Luego, los systems en la scene procesan la lista de `Transform` components uno por uno, sin hacer ninguna distinción. Todos los `Transform` components tienen los mismos campos y pasan por las mismas comprobaciones. ![](/files/33ff52123a180fd8febb15d29f7de244831eb8e0) Imagina una scene que tiene una docena de puertas que pueden estar abiertas o cerradas. Puedes representar el estado de todas estas puertas como un simple component "isOpen" que contiene un valor booleano. Si "isOpen" es true, la puerta debe estar abierta; si es false, la puerta debe estar cerrada. Si un player hace click en una puerta, su estado debe alternarse, y otros players también deberían verlo alternarse. Mientras tu scene procesa un cambio en el estado de una puerta y lo sincroniza con otros players, realmente no le importa lo que representa "isOpen". El conjunto completo de components es solo una colección de booleanos que deben sincronizarse con otros players. Un system separado en tu scene puede entonces encargarse de igualar regularmente el estado de cada "isOpen" con la rotación de la puerta correspondiente. La programación orientada a datos no es necesariamente más difícil, pero sí es un enfoque distinto que hay que aprender y adoptar. Los developers que no están acostumbrados a este enfoque podrían necesitar algo de tiempo para familiarizarse con él; te animamos a explorar y probar ejemplos para entenderlo mejor. ## Por qué funciona Para entender por qué la programación orientada a datos marca una diferencia tan grande, necesitamos echar un vistazo al hardware. Cuando el processor necesita obtener datos de la memoria, recupera un bloque completo de datos en la cache, incluidos datos que casualmente están escritos en la memoria junto al valor que queríamos. Cuanto más pueda tu code aprovechar datos que ya están en cache, más rápido se ejecutará tu code. Imagina que la memoria de la máquina es un almacén literal, donde los datos se guardan en muchas cajas apiladas. Cada vez que necesitamos una cierta cantidad de datos, debemos llamar a un montacargas para que vaya a buscar la caja donde se encuentran esos datos y la lleve al mostrador para inspeccionarla. Ese mostrador solo puede contener un par de cajas a la vez, así que no puedes tener mucho datos alrededor. El montacargas tarda mucho en ir hasta el fondo del almacén y traernos una caja. Si los datos que quieres de estas cajas están dispersos, eso significará pedirle al montacargas que haga muchos viajes. La mayor parte del tiempo, estarás esperando con los brazos cruzados junto al mostrador, esperando a que llegue la siguiente caja que pediste. Puedes evitar gran parte de ese tiempo perdido si apilas estas cajas de forma inteligente y empaquetas los datos para que las cosas que probablemente necesites al mismo tiempo estén, en su mayoría, agrupadas. Si agrupas los datos de manera inteligente, a menudo descubrirás que lo siguiente que necesitas ya está en una de las cajas del mostrador. Podrás ir directamente a ello sin molestar al operador del montacargas. Por ejemplo, si tienes una scene que necesita obtener el estado de una puerta para comprobar si está abierta o cerrada, el hardware no solo está obteniendo el valor del booleano específico que describe el estado de esa puerta; también está obteniendo un montón de otros datos que pueden o no ser relevantes. Supón que tu scene tiene un system que necesita actualizar el estado abierto/cerrado de una docena de puertas, una vez por frame. Si tu code está organizado siguiendo un enfoque de programación orientada a objetos, no hay forma de saber cómo podrían agruparse los distintos fragmentos relevantes de información. Tal vez una "caja" de nuestro almacén contenga el estado "isOpen" de la puerta A y también la textura de la puerta A y el audio que reproduce al abrirse. Puede que tengas que hacer un viaje para obtener una nueva "caja" de datos por cada una de las docena de puertas. Y, por supuesto, todo este proceso debe volver a ocurrir en cada frame. Así que eso son 360 (30 x 12) viajes metafóricos al fondo del almacén por segundo, incluso cuando ninguna de las puertas ha cambiado de estado. Si tu code sigue, en cambio, un enfoque orientado a datos, es muy probable que esos 12 booleanos estén en la misma caja. Esto se debe a que todos esos booleanos forman parte de un único array que se registró en memoria al mismo tiempo. Nunca organizas explícitamente cómo encajan estos datos en la memoria, así que, en el peor de los casos, el array podría terminar dividido entre dos cajas. Pero incluso en ese peor escenario, 2 viajes es mucho mejor que 12. Comprobar el estado de cada puerta en cada frame suena como mucho trabajo, pero en realidad es súper rápido si todos los datos ya están en la cache de memoria. Si tus datos están bien organizados, tu scene puede ejecutar procesos como estos sobre muchas entities y aun así funcionar realmente rápido. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.decentraland.org/creator/content-creator-es/scenes-sdk7/arquitectura/data-oriented-programming.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.