Come applicare la progettazione orientata ai dati con la programmazione orientata agli oggetti? [chiuso]

Chiuso . Questa domanda deve essere più focalizzata . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che si concentri su un problema solo modificando questo post .

Chiuso 4 anni fa .

Ho letto molti articoli su Data Oriented Design (DOD) e lo capisco ma non riesco a progettare un sistema di programmazione orientata agli oggetti (OOP) con DOD in mente, penso che la mia formazione OOP mi stia bloccando. Come dovrei pensare di mescolare i due? L'obiettivo è avere una bella interfaccia OOP mentre si usa DOD dietro le quinte.

Ho visto anche questo, ma non ha aiutato molto: /programming/3872354/how-to-apply-dop-and-keep-a-nice-user-interface

c++ architecture

— Pombal
fonte

È necessario inviare qualcosa di molto più specifico (e gioco-correlato), la questione è di gran lunga troppo generica.

— DeadMG

Hai ragione, ma non ho visto questo essere discusso in altri campi oltre alla programmazione del gioco.

— Pombal,

@DeadMG: non ho mai visto il termine design orientato ai dati utilizzato al di fuori dello sviluppo del gioco, tranne quando si riferiva a pratiche originate dallo sviluppo del gioco. Se stai pensando alla progettazione basata sui dati, non è la stessa cosa.

Direi che il blog di Noel Llopis è probabilmente la migliore istruzione per una combinazione di programmazione orientata agli oggetti e progettazione orientata ai dati. È uno dei creatori del termine DOD, è un forte programmatore C ++ e ha scritto molto sul suo stile e su come sfrutta le funzionalità OO di C ++.

Immagino che se dovessi chiamare gli elementi chiave della loro combinazione, secondo Noel:

Utilizzare il più possibile le funzioni POD e non membro, non amico. Le funzioni non membro e non amico migliorano l'incapsulamento e sono una parte fondamentale dell'orientamento ai dati perché mantengono i dati, i dati.
Evitare di memorizzare lo stato "temporaneo" sugli oggetti. Lo stato temporaneo blocca i tuoi dati. Se è necessario memorizzare nella cache qualcosa (ad esempio per le prestazioni), quello appartiene a una nuova classe, con funzioni non amiche non membro che collegano i due tipi, non una relazione is-a né has-a.
Evita oggetti che possono trovarsi nello stato A o nello stato B. Preferisci alternare tra due oggetti, uno dei quali è A e uno dei quali è B.
Evita il polimorfismo, evita le funzioni virtuali, evita i template, evita qualsiasi cosa che renda i tuoi dati l' aspetto sintattico dell'identità piuttosto che l' effettiva identità.

L'altro grande nome della propaganda DOD in questo momento è Mike Acton di Insomniac, ma leggendo quello che ha scritto direi che non è davvero pro-OO (o anti-OO, purché sia ancora orientato ai dati).

Grazie per la risposta, ma quello che stai dicendo è cosa dovrei fare per usare DOD, non come potrei usare OO con esso. Ho letto il blog di Noel, i rants di Mike Acton (: D), le pubblicazioni di DICE tra gli altri e capisco come usare DOD, ma non con OO mischiato.

— Pombal

Cosa pensi che sia OO? Vorrei chiamare la maggior parte del codice OO di Noel, ad esempio - ci sono ancora classi e istanze, c'è ancora una spedizione basata sul tipo, potrebbe esserci ancora eredità (la definizione di P ++ 0x di POD è stata modificata per consentire ciò). Uno ancora modella i problemi a partire dai dati, piuttosto che dalle operazioni.

Ad esempio il polimorfismo è una parte significativa di OOP, così come lo sono gli stati dell'oggetto. Il design orientato ai dati dovrebbe essere quello di dare alle entità di gioco proprietà come animabile, interagibile, spostabile, ... usando l'ereditarietà. Tutto dipende da un intelligente gestore di dati che fornisce solo le entità necessarie a ciascun componente, ad esempio per la fisica o l'animazione.

— danijar,

@sharethis: se capisco la tua obiezione, è che il polimorfismo del sottotipo è una caratteristica chiave di OO. Concordo sul fatto che un linguaggio che afferma di essere OO senza supporto per esso sarebbe strano, ma ciò non significa che sia uno strumento di primo ricorso per il tipo di problemi che si incontrano durante la programmazione dei giochi, anche quando il gioco è programmato in uno stile OO . Direi anche che DOD si occupa davvero di evitare particolari tipi di polimorfismo (sottotipizzazione nominale) ma di incoraggiare gli altri (in C ++, polimorfismo ad hoc con ADL, o polimorfismo strutturale attraverso garanzie su rappresentazioni di valore).