Prośba o ocenę gry c++

Question

Witam!

Zabawę z c++ zacząłem dość dawno. Po obejrzeniu wszystkich filmów pana Mirosława Zelenta i przeczytaniu kilku artykułów na temat c++ właśnie postanowiłem stworzyć jakąś fajną aplikację, niestety kiedy próbowałem wykorzystać podejście obiektowe zawsze coś nie wychodziło... Zraziłem się trochę i porzuciłem na jakiś czas c++ ale potem doszedłem do wniosku, że warto spróbować jeszcze raz. Stworzyłem grę polegającą na zbieraniu "pieniążków" z poruszaniem się w stylu snake'a.

Kod źródłowy: https://gist.github.com/anonymous/dec9b753e5bef4ee2b734d0060e2e99d#file-main-cpp

Wiem, że zapewne jak to w pierwszym "większym" projekcie jest tam pewnie sporo niedociągnięć, ale chciałbym wiedzieć co o tym sądzicie.

Comments

Niedawno pisałem, że obiektowe programowanie gier jest trudne. Miałem oczywiście wtedy rację :) Pierwsze co się rzuca w oczy to publiczne gettery. Ja to nazywam bezczelnymi akcesorami bo bezczelnie ujawniają całą strukturę obiektu tak jakby była to struktura danych. Wujek Bob nazwał takie twory hybrydami bo zawierają wady zarówno struktur danych jak i obiektów. Jeśli programowanie obiektowe ci nie wychodzi to się nie martw bo programując strukturalnie można zrobić naprawdę rozbudowane gry. Jako przykład może posłużyć Warcraft 3. Genialna gra, dzięki której powstały inne świetne tytuły takie jak Dota. Wszystko to programując strukturalnie w oparciu o język JASS stworzony przez Blizzarda.

---

Co byś proponował zmienić?

---

Przenieś swoje akcesory do chronionych albo prywatnych.

---

Nie do końca rozumiem jaki jest sens ustawiać akcesory jako prywatne... Przecież ich idea to dostęp do danych z innych klas...

---

Widać, że nie rozumiesz istoty programowania obiektowego, ale to nie nowość w przypadku ludzi, którzy obejrzeli kurs Zelenta. Polecam przeczytać profesjonalne książki np Czysty Kod, Wzorce Projektowe.

---

Nie wszystkie gettery i settery są bezczelnymi akcesorami zmiennych. Na przykład metoda setBackgroundColor może po prostu odnosić się do funkcji OpenGL, która zmienia kolor tekstury. Zmienna Background Color może nawet nie istnieć.

Drugi przykład getCollisionBody. W tym przypadku mamy właściwie pewność, że zmienna CollisionBody nawet nie istnieje, a sama metoda przeprowadza zaawansowane operacje.

Może się zdarzyć, że zarówno set i get nie są bezczelnymi akcesorami, np w przypadku listy jednokierunkowej, metody te wykonują operację szukania wartości węzła o wskazanym numerze.

We wszystkich tych przypadkach set i get mogą być publiczne. Twoje akcesory udostępniają po prostu zmienne, dlatego trzeba je ochronić. Jeśli chcesz coś zrobić ze zmiennymi X i Y to klasa, która posiada te zmienne powinna tą operację wykonywać.

---

Jeżeli publiczne akcesory są problemem to widzę kilka rozwiązań:

1. Całkowicie je usunąć i zmienić klauzulę z private na public (hmm... może lepiej nie) albo protected (nie będzie dostępu "od zewnątrz" ale od klas dziedziczących dostęp będzie jeszcze bardziej "bezczelny")
2. Zamiast akcesorów zastosować system przyjaźni (W sumie to wiem, że takie coś jest ale jakoś nigdy nie korzystałem)
3. Zmienić akcesory z public na protected 

Co uważasz za najlepsze rozwiązanie?

A co do:

 

Nie wszystkie gettery i settery są bezczelnymi akcesorami zmiennych. Na przykład metoda setBackgroundColor może po prostu odnosić się do funkcji OpenGL, która zmienia kolor tekstury. Zmienna Background Color może nawet nie istnieć.

Drugi przykład getCollisionBody. W tym przypadku mamy właściwie pewność, że zmienna CollisionBody nawet nie istnieje, a sama metoda przeprowadza zaawansowane operacje.

Wszystko ok, ale zauważ, że "collector" to prosta gierka konsolowa, w której nie ma po prostu potrzeby przeprowadzać zaawansowanych operacji w getterach czy setterach.