Autor Wątek: Ocena kodu  (Przeczytany 1288 razy)

Offline jelcynek

  • Użytkownik

# Październik 18, 2011, 19:35:44
Witam. Jestem początkującym koderem gier. Programowanie strukturalne mam opanowane, lecz obiektowe od strony teoretycznej przyswoiłem sobie całkiem nieźle, lecz w praktyce dopiero robię pierwsze kroki. Właściwie poniższy kod to pierwszy obiektowy program napisany przeze mnie w cpp od podstaw. Być może tak usilne pisanie zwykłego węża w formie obiektowej to przerost formy nad treścią. Jednak chciałem trochę poćwiczyć, robiąc małe kroczki i zaczynając od prostych gier.

Jeśli chodzi o stronę merytoryczną to wiem, że gra prezentuje się "biednie" i można wiele dodać. Ale nie o to chodziło by spędzać czas na implementowaniu wodotrysków, gdy ja obiektowość muszę trenować! Dlatego też proszę o ocenę kodu pod kątem programistycznym, szczególnie interesują mnie uwagi dotyczące obiektowej budowy kodu. Wszystko to jest jeszcze takie nowe i nie chcę powtarzać tych samych błędów w kolejnych projektach.

Sam już teraz mam kilka wątpliwości. Nie wiem czy stałe definiowane w defines.h nie łamią idei hermetyzacji. Czy może powinienem je umieścić w odpowiadających im klasach?

Myślę, że nie do końca oddzieliłem funkcję pliku głównego od klasy App, bo właściwie ciężko jest rozróżnić namacalnie co za co odpowiada. Być może powinienem wszystko wrzucić do klasy app.

Niejednoznaczne jest także użycie dwóch bibliotek "conio.h" i "wincon.h". Wszystko co trzeba można obsłużyć przy pomocy biblioteki windowsowej, jednak chciałem program skończyć jeszcze w pracy ;], więc nie miałem czasu ogarniać obsługi wejścia w bibliotece "wincon.h". Dlatego też getch() i kbhit() zostały.

Acha, błędy ortograficzne w nazwie są celowe ;].
Kod załączam do posta.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Październik 18, 2011, 19:46:19
Po prostu pisz, pisz pisz a nie patrz na teorie obiektowości.

Offline kapec94

  • Użytkownik

# Październik 18, 2011, 23:49:38
Muszę przyznać, że ładnie kod wygląda. Tu i ówdzie pozmieniałbym jednak typy wartości zwracanych i argumentów na referencje, tj. wszędzie tam, gdzie nie są to typy podstawowe oraz define'y lub typedef'y z nimi w roli głównej.

Zresztą zgadzam się z @up. Dopóki wszystko ze sobą współgra, masz dobrze napisany kod. niezależnie od przyjętego paradygmatu.