Tietoihin suuntautunut vs. kohdekeskeinen suunnittelu

Videopelit ovat ahneita. He voivat vaatia valtavan määrän RAM-muistia, prosessointitehoa ja yleensä rasittaa fyysistä laitteistoa, joka vastaa tietojen noutamisesta, käsittelemisestä ja palauttamisesta. Tästä syystä useita datakeskeisen suunnittelun kannattajia on noussut sanomaan, että objektiohjattu suunnittelu ei ehkä ole paras tapa järjestää koodi, joka käyttää näitä monoliittisia sovelluksia.

Joten mikä on datakeskeistä suunnittelua, miten se eroaa OOP: sta, ja mitkä ovat säännöt, jotka koskevat kuinka ajatella DOP-koodin kirjoittamista?

Miten se eroaa OOP: sta?

Kuten nimensä päättelee, olio-ohjelmointi keskittyy objektien määrittelemiseen, tuottamiseen ja käyttämiseen. Se ohjaa kooderit:

  1. Määritä, mitkä esineet ovat.
  2. Määritä, minkä tyyppiset tiedot objektiin kuuluvat.
  3. Kuvaile esineen toiminnallisuutta.

Nämä objektit ovat sitten vuorovaikutuksessa muiden objektien kanssa niiden toimintojen kautta, jotka kukin objekti omistaa.

Kuinka esineet toimivat OOP: ssa

Yksi OOP: n suurista eduista on, kuinka tarkasti se näyttää heijastavan miten olemme tekemisissä reaalimaailman kanssa. Esimerkiksi, kun tiedän jotain ”Pöydät” -luokasta, voin säästää itselleni paljon aikaa tietämällä mitä voin ja mitä en voi tehdä pöydällä. Et koskaan osoittaisi taulukon esiintymää ja kysyisi "millaista cappuccinoa tämä taulukko tekee?", Koska taulukkoluokka ei anna taulukoille toiminnallisuutta cappuccinon valmistamiseksi.

Tästä konseptista saadaan myös hyöty polymorfismista (Poly - Many; Morph - Forms), joka kuvaa oliokeskeisen ohjelmoinnin mallia, jossa luokilla on erilaiset toiminnot samalla kun jaetaan yhteinen rajapinta. Jos ajattelet eläinten luokittelua tietämällä, että kissa ja tiikeri kuuluvat ”kissan” luokkaan, tiedän automaattisesti paljon jokaisesta heistä sukeltamatta heidän luokkiensa erityispiirteisiin. He molemmat "perivät" tietyt ominaisuudet ja tiedot kissan ylemmästä luokasta.

Mutta tässä paradigmassa toiminnot rajoittuvat tiettyihin tietoihin, eikä niitä voida käyttää uudelleen. Jos haluat, että funktio toimii erilaisella objektilla objektissa, toiminnon on joko perittävä pääluokasta tai se on kirjoitettava uudelleen. On tärkeätä miettiä, kuinka vanhemmalta luokalta perittyyn luokkaan kuuluviin tietoihin pääsee tässä paradigmassa. Tiedot on haettava useiden luokkien kautta prosessorille pääsemiseksi, mikä voi olla tehotonta.

Esimerkki prosessorista, joka prosessorin on ehkä tehtävä OOP-järjestelmässä.

Dataorientoitu ohjelmointi lähestyy koodausta hieman eri tavalla. Objektien sijasta kaikki on tietoa ja kaikkiin voidaan toimia. Tämä erottaa toiminnallisuuden ja datan. Niitä ei enää ole toisiinsa sidoksissa erityisen sääntöjoukon avulla. DOP-toiminnossa toiminnot ovat yleiskäyttöisiä ja niitä käytetään suuriin datapalasiin. Ihannetapauksessa järjestäisit tiedot mahdollisimman lähelle lähtödataa varmistaaksesi, että itse toiminto tekee mahdollisimman vähän vaivaa.

"Data-Oriented Design siirtää ohjelmoinnin näkökulman objekteista itse tietoon: Tiedon tyyppi, kuinka se asetetaan muistiin ja miten se luetaan ja käsitellään pelissä."
Esimerkki DOP-puhelusekvenssistä. Paljon vähemmän työtä prosessorille.

Miksi DOP?

Yksinkertainen vastaus on, koska prosessorit rakastavat referenssipaikasta. Nämä säännöt sanelevat monia muita etuja, jotka meille on annettu DOP: lla. Esimerkiksi referenssipaikallisuutta optimoivan koodin kirjoittaminen antaa meille paljon helpomman tavan toteuttaa rinnakkaistaminen. Parallelization -yrityksellä yritetään käyttää useampaa kuin yhtä tietokoneprosessorin ydintä tehtävien suorittamiseen samanaikaisesti. Tämä voi olla erittäin vaikea tehdä OOP: n kanssa, koska olet vaarassa, että prosessori käyttää useita ketjuja yrittämään samanaikaisesti käyttää samoja tietoja. Kuitenkin, kun ryhmität samanmieliset tiedot yhteen ja kirjoitat koodin keskittyen yleensä käsiteltävään tietoon, on huomattavasti helpompaa käyttää prosessorin useita säikeitä näiden toimintojen käsittelemiseen.

Toinen DOP: n etu on tehokas muistivälimuistin käyttö. Koska DOP käyttää samoja toimintoja uudestaan ​​ja uudestaan, välimuistia ei pakoteta säilyttämään yhä enemmän uusia, mutta ei todellakaan uusia ohjeohjeita.

Lähteet

https://www.danielsefton.com/2016/05/developing-a-data-oriented-game-engine-part-1/

https://www.packtpub.com/books/content/what-difference-between-functional-and-object-oriented-programming

https://www.gamasutra.com/view/news/126498/Opinion_What_You_Need_To_Give_Up_When_Going_Data_Oriented.php

https://prateekvjoshi.com/2013/11/30/programming-paradigms-object-oriented-vs-data-oriented/

http://gamesfromwithin.com/data-oriented-design