Jak zastosować projektowanie zorientowane na dane za pomocą programowania obiektowego? [Zamknięte]


17

Przeczytałem wiele artykułów na temat projektowania zorientowanego na dane (DOD) i rozumiem to, ale nie mogę zaprojektować systemu programowania obiektowego (DOP) z myślą o DOD, myślę, że moja edukacja OOP mnie blokuje. Jak powinienem wymieszać te dwa? Celem jest mieć ładny interfejs OOP podczas korzystania z DOD za kulisami.

Też to widziałem, ale niewiele pomogłem : /programming/3872354/how-to-apply-dop-and-keep-a-nice-user-interface


3
Trzeba dodawać coś znacznie bardziej szczegółowe (i związane z grą), to pytanie jest zdecydowanie zbyt ogólne.
DeadMG,

Masz rację, ale nie widziałem, aby omawiano to w innych dziedzinach oprócz programowania gier.
Pombal

4
@DeadMG: Nigdy nie spotkałem się z pojęciem projektowania zorientowanego na dane używanym poza tworzeniem gier, z wyjątkiem odniesień do praktyk związanych z tworzeniem gier. Jeśli myślisz o projektowaniu opartym na danych, to nie to samo.

Odpowiedzi:


16

Powiedziałbym, że blog Noela Llopisa jest prawdopodobnie najlepszą instrukcją dla kombinacji programowania obiektowego i projektowania zorientowanego na dane. Jest jednym z pomysłodawców terminu DOD, jest silnym programistą w C ++, i napisał sporo o swoim stylu oraz o tym, jak wykorzystuje funkcje OO w C ++.

Według Noela, gdybym przywołał kluczowe elementy ich łączenia:

  • Korzystaj z funkcji POD i funkcji nie będących członkami, nieprzyjacielem w jak największym stopniu. Funkcje nie będące członkami, nieprzyjazne poprawiają enkapsulację i są kluczowym elementem orientacji na dane, ponieważ przechowują dane, dane.
  • Unikaj przechowywania stanu „tymczasowego” na swoich obiektach. Stan tymczasowy zapycha twoje dane. Jeśli musisz buforować coś (np. W celu zwiększenia wydajności), należy to do nowej klasy, a funkcje nieprzyjazne niebędące członkami łączą te dwa typy, a nie relację typu „nie jest ani nie ma”.
  • Unikaj obiektów, które mogą znajdować się w stanie A lub B. Preferuj przełączanie między dwoma obiektami, z których jeden to A, a drugi B.
  • Unikać polimorfizm, unikać funkcje wirtualne, szablony uniknąć, należy unikać wszystkiego, co sprawia, że dane mają składniowej wygląd o identyczności raczej niż rzeczywistą identyczność.

Innym wielkim nazwiskiem w propagandzie DOD jest teraz Mike Acton z Insomniac, ale czytając to, co napisał, powiedziałbym, że tak naprawdę nie jest pro-OO (ani anty-OO, o ile nadal jest zorientowane na dane).


Dziękuję za odpowiedź, ale to, co mówisz, jest tym, co powinienem zrobić, aby korzystać z DOD, a nie jak mogę z tym korzystać z OO. Czytałem blog Noela, rant Mike'a Actona (: D), publikacje DICE i rozumiem, jak korzystać z DOD, ale nie z włączonym OO.
Pombal

2
Jak myślisz, czym jest OO? Na przykład nazwałbym większość kodu Noela OO - wciąż istnieją klasy i instancje, nadal istnieje wysyłka oparta na typach, może nadal istnieć dziedziczenie (definicja POD POD C ++ 0x została zmieniona, aby to umożliwić). Nadal modeluje się problemy zaczynające się od danych, a nie operacji.

Na przykład polimorfizm jest znaczącą częścią OOP, podobnie jak stany obiektu. Projekt zorientowany na dane powinien nadawać jednostkom gry takie właściwości, jak animowanie, interakcja, zdolność przenoszenia, ... dziedziczenie. Wszystko zależy od inteligentnego menedżera danych, który zapewnia tylko potrzebne elementy do każdego komponentu, np. Do fizyki lub animacji.
danijar

@sharethis: Jeśli rozumiem twój sprzeciw, to polimorfizm podtypu jest kluczową cechą OO. Zgadzam się, że język, który twierdzi, że jest OO bez wsparcia, byłby dziwny, ale to nie znaczy, że jest to narzędzie pierwszej pomocy dla problemów, jakie napotyka się podczas programowania gier, nawet jeśli gra jest zaprogramowana w stylu OO . Argumentowałbym również, że DOD tak naprawdę polega na unikaniu określonych rodzajów polimorfizmu (nominalne podtypowanie), ale zachęcaniu innych (w C ++, polimorfizm ad hoc z ADL lub polimorfizm strukturalny poprzez gwarancje reprezentacji wartości).
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.