> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-pt/scenes-sdk7/arquitetura/data-oriented-programming.md). # Programação Orientada a Dados A Programação Orientada a Dados é uma abordagem poderosa de programação que aproveita ao máximo o desempenho. A Programação Orientada a Dados é uma abordagem poderosa à programação que resulta em grandes melhorias de desempenho. Ela foca-se em tratar *dados* como o elemento central; tudo o resto é organizado em torno dele, para aceder ou modificar esses dados. Esta abordagem também é muito adequada para multiplayer, pois torna os dados que precisam de ser sincronizados entre jogadores mais fáceis e rápidos de aceder. A Programação Orientada a Dados incentiva-o a pensar em tudo na sua scene como dados que precisam de ser copiados e alterados ao longo dos vários systems. O principal benefício desta abordagem é otimizar a velocidade com que os dados podem ser lidos da memória, que muitas vezes é o principal gargalo ao executar aplicações e jogos modernos. Devido a esta melhoria notável de desempenho, grande parte da indústria de criação de jogos tem vindo a adotar esta abordagem ao longo dos últimos anos. O SDK do Decentraland executa scenes em JavaScript, e uma desvantagem desta linguagem é que não oferece controlo sobre a alocação de memória. O Engine que executa o Decentraland, no entanto, usa C#, que beneficia bastante ao seguir princípios orientados a dados. O SDK e o Engine estão constantemente a enviar mensagens entre si. Para tornar esta comunicação o mais eficiente possível, faz sentido manter as estruturas de dados em ambos os lados o mais semelhantes possível, para evitar ter de reorganizar constantemente estes dados. ## Como fica A Programação Orientada a Dados é diferente da Programação Orientada a Objetos, uma abordagem com a qual muitos desenvolvedores estão atualmente familiarizados. Na Programação Orientada a Objetos, o código é estruturado seguindo abstrações que tentam replicar construções do mundo real: objetos. Cada um destes objetos pode conter tanto dados como funcionalidade. As aplicações que usam esta abordagem são muitas vezes fáceis de planear em termos conceptuais, mas também mais ineficientes de executar. Na Programação Orientada a Dados, os dados não são estruturados em torno de objetos; são estruturados para otimizar a sua facilidade de acesso. As construções do mundo real que os dados representam não desempenham qualquer papel nos diferentes fluxos que alteram esses dados. O modelo Entity Component System (ECS) sobre o qual o SDK do Decentraland é construído é muito compatível com a abordagem da Programação Orientada a Dados. Cada component faz parte de uma coleção estruturada de dados. Components pertencem a uma entity por referência, mas os dados não são estruturados em torno da entity; os dados são estruturados como uma coleção de components semelhantes. Por exemplo, todos `Transform` components in a scene are equal. Um destes Transforms pode pertencer ao modelo do seu edifício principal, outro a um vidro que é filho de uma mesa. Os systems na scene processam então a lista de `Transform` components um a um, sem fazer distinções. Todos `Transform` components têm os mesmos campos e passam pelas mesmas verificações. ![](https://2402076176-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-2f8795b95cc1b4e9f2a9e37cdb54e9841d123b46%2Fcomponent-stacks.png?alt=media\&token=48e03f10-ead9-4cbd-b4c8-f1ff708c1c13) Imagine uma scene que tem uma dúzia de portas que podem estar abertas ou fechadas. Pode representar o estado de todas estas portas como um simples component "isOpen" que contém um valor booleano. Se "isOpen" for true, a porta deve estar aberta; se for false, a porta deve estar fechada. Se um jogador clicar numa porta, ela deve alternar de estado, e os outros jogadores também devem ver essa alternância. Enquanto a sua scene está a processar uma alteração no estado de uma porta e a sincronizá-la com outros jogadores, a scene não se importa realmente com o que "isOpen" representa. Todo o conjunto de components é apenas uma coleção de booleanos que precisam de ser sincronizados com outros jogadores. Um system separado na sua scene pode então encarregar-se de corresponder regularmente o estado de cada "isOpen" à rotação da porta correspondente. A Programação Orientada a Dados não é necessariamente mais difícil, mas é uma abordagem diferente que precisa de ser aprendida e adotada. Os desenvolvedores que não estão habituados a esta abordagem podem precisar de algum tempo para se familiarizarem com ela; encorajamos a que explore e experimente exemplos para a sentir melhor. ## Porque funciona Para entender porque a Programação Orientada a Dados faz tanta diferença, precisamos de olhar para o hardware. Quando o processador precisa de ir buscar dados da memória, ele carrega um bloco inteiro de dados para a cache, incluindo dados que por acaso estejam escritos na memória ao lado do valor que queríamos. Quanto mais o seu código conseguir usar dados que já estão na cache, mais rápido o seu código vai executar. Imagine que a memória da máquina é um armazém literal, onde os dados são armazenados em muitas caixas empilhadas. Sempre que precisamos de uma certa parte de dados, precisamos de chamar uma empilhadeira para ir buscar a caixa onde esses dados se encontram e trazê-la para o balcão da frente para inspeção. Esse balcão só consegue acomodar algumas caixas de cada vez, por isso não se consegue manter muitos dados por perto. A empilhadeira demora muito tempo a ir até ao fundo do armazém e trazer-nos uma caixa. Se os dados que quer dessas caixas estiverem espalhados, isso significará pedir à empilhadeira para fazer muitas viagens. Na maior parte do tempo, ficará de braços cruzados junto ao balcão da frente, à espera que chegue a próxima caixa que pediu. Pode evitar grande parte desse tempo desperdiçado se empilhar estas caixas de forma inteligente e organizar os dados para que as coisas de que provavelmente vai precisar ao mesmo tempo fiquem maioritariamente agrupadas. Se agrupar os dados de forma inteligente, muitas vezes vai descobrir que a próxima coisa de que precisa já está numa das caixas no balcão da frente. Poderá avançar diretamente sem incomodar o operador da empilhadeira. Por exemplo, se tiver uma scene que precise de obter o estado de uma porta para verificar se está aberta ou fechada, o hardware não está apenas a obter o valor do boolean específico que descreve o estado dessa porta; está também a obter uma grande quantidade de outros dados que podem ou não ser relevantes. Suponha que a sua scene tem um system que precisa de atualizar o estado aberto/fechado de uma dúzia de portas, uma vez por frame. Se o seu código estiver organizado segundo uma abordagem de Programação Orientada a Objetos, não há como saber de que forma as diferentes partes relevantes da informação poderão estar agrupadas. Talvez uma "caixa" do nosso armazém contenha o estado "isOpen" da porta A e também a textura da porta A e o áudio que reproduz quando abre. Talvez tenha de fazer uma viagem para obter uma nova "caixa" de dados para cada uma das doze portas. E, claro, todo este processo precisa de acontecer novamente em cada frame. Portanto, são 360 (30 x 12) viagens metafóricas ao fundo do armazém por segundo, mesmo quando nenhuma das portas mudou de estado. Se, por outro lado, o seu código seguir uma abordagem Orientada a Dados, é muito provável que todos esses 12 booleanos estejam na mesma caixa. Isto porque todos estes booleanos fazem parte de um único array que foi gravado na memória de uma só vez. Nunca está explicitamente a organizar a forma como estes dados cabem na memória, por isso, no pior cenário, o array pode acabar dividido por duas caixas. Mas, mesmo nesse pior cenário, 2 viagens é muito melhor do que 12. Verificar o estado de cada porta em cada frame parece muito trabalho, mas na verdade é super rápido se todos os dados já estiverem na cache da memória. Se os seus dados estiverem bem organizados, a sua scene pode executar processos como estes sobre muitas entities e ainda assim correr muito depressa. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.decentraland.org/creator/content-creator-pt/scenes-sdk7/arquitetura/data-oriented-programming.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.