Data-oriented design: Difference between revisions

Revision as of 23:01, 1 July 2023

Revision as of 17:03, 5 September 2023

Line 5:

Strategies and patterns emerging from the notion of modelling via transforms often base themselves upon allowing assumptions about a [[Computer program|program]] or [[subprogram]]'s [[State (computer science)|state]]. Examples such as [https://www.dataorienteddesign.com/dodbook/node4.html Existential Processing]<ref>{{Cite web |title=Existential Processing |url=https://www.dataorienteddesign.com/dodbook/node4.html |access-date=2023-06-01 |website=www.dataorienteddesign.com}}</ref> and [https://www.dataorienteddesign.com/dodbook/node6.html Hierarchical Level of Detail]<ref>{{Cite web |title=Hierarchical Level of Detail |url=https://www.dataorienteddesign.com/dodbook/node6.html |access-date=2023-06-01 |website=www.dataorienteddesign.com}}</ref> are all integral proponents of the core design principles.

As a programming paradigm, '''data-oriented programming''' (also commonly referred to as data-oriented design), is about implementing '''transforms''' into the native language, often with [[Procedural programming|Procedural]], [[Functional programming|Functional]], and [[Array programming|Array]] programming, though not limited from [[Object-oriented programming]]. To most optimally transform data between different states, the approach is to first focus on what transforms exist and discovering what they need to operate. Second is to optimize data layouts for these transforms, separating and sorting [[field (computing)|fields]] according to when they are needed, and to think about how data flows through the transform chains.