Hogyan érdemes egy összetett programot írni?

Én objektumorientált szemlélettel csinálnám meg. Első körben végiggondolnám, milyen elemei vannak a játéknak. A játék egyszerű, van egy N*N méretű táblája mindkét játékosnak, amire leraknak X torpedót. A játékosok felváltva lépnek, kijelölve egy mezőt, és ha talál, újra ugyanaz a játékos léphet. Akkor nyer valaki, ha az ellenfele összes torpedóját kilövi. Szóval, a játék szempontjából a következő dolgok lesznek nekünk fontosak:

1) A torpedó.

2) Az egyik játékos táblája.

3) Fontos lesz a játék aktuális állapota (mely táblára hová lőttek, melyik játékos következik stb.)

4) Kell maga a játékos.

5) Kell a logika, ami vezérli a játékmenetet.

6) Valamint kell egy UI vezérlő komponens, ami a játékos számára ismertté teszi a játékállapotot.

Először oda próbálnék eljutni, hogy legyen meg a torpedó, a tábla és a játékállapot objektumorientált reprezentációja (vagyis legyen egy-egy osztály mindegyikhez), valamint kell egy interfész, ami a játékost írja le. Ezek az alapvető dolgok, amik ha megvannak, elkezdhetsz dolgozni a játékvezérlő logikán. És ezt apró lépésekben elkezded fejleszteni:

1) Tudj elindítani egy új játékot. És írsz egy unit tesztet, ami megvizsgálja, hogy mindkét tábla üres.

2) Tudj kiválasztani egy kezdő játékost. Erre lehet, érdemes új komponenst bevezetni. És unit teszttel teszteled, hogy valóban annak a játékosnak kell-e először torpedót raknia.

És így tovább. Tehát bár a programoddal még nem tudsz kapcsolatba lépni (nem tudsz vele játszani, azaz manuálisan tesztelni), de automata egységtesztekkel meg tudod hajtani.

Ha megvagy mindennel, akkor egy dependency injection rendszert állíts csatasorba, hogy ezt a nagy hóbelebancot be tudja valami indítani. Viszont ennek az architektúrának nagyon nagy előnyei vannak:

1) a programod alaposan tesztelt lesz

2) bármelyik részét bármikor ki tudod úgy cserélni, hogy ne törj el semmi mást a programban - például simán megcsinálhatod, hogy a másik játékos az interneten keresztül játszik

3) könnyen karbantartható

Bonyolultan hangzik, és hatalmas a tanulási görbe, viszont rengeteget tanulhatsz így.

Az alapokat nem kell újra tanulni, csak tovább kell haladni, építeni rájuk új infókat, új szemléletet, tervezési módokat.

"Ha csak az alapjátékot írom meg és később egészítem ki akkor nagy a hibalehetőség nem? Egyben megírva pedig nehezebb lenne főleg kezdőként."

A "leülök és megírom a progit" dolog csak nagyon kis projekteknél működik, amúgy először meg kell tervezni, legalább minimális szinten, mielőtt akár egyetlen kódsort is beírnál. Van egy bonyolultsági szint, ahol már nem működik a fejben összerakás és a menet közbeni kitaláció. Muszáj lesz előre átgondolni, hogy mit akarsz, milyen elemekre lesz szükség, azoknak mi kell legyen a pontos feladatuk, milyen adatokkal dolgoznak és mit állítsanak elő, ezek a részek milyen elv szerint fognak együtt dolgozni, kommunkálni egymással, stb. Ebben pl. nagyon erős az objektumorientált szemlélet, de itt is fontos az előzetes tervezés.

[link]

[link]

[link]

stb....

Valójában egy igen régi problémába futottál bele. :)

[link]

"... Az ember képessége a bonyolultság áttekintésére korlátozott, mindig új és új módszereket kell kitalálni az egyre összetettebb feladatok biztonságos és hatékony megoldásához."

Csak egy hevenyészett példa, osztályokra:

- Game, ami egy játékot reprezentál. Tulajdonságai, hogy ki jön, ki nyert, tartalmazza (ld.: asszociáció, aggregáció, kompozíció) pl. a játékosokat, a tábláikat (ezeket párba is rendezheti), és ezzel van mondjuk interakcióban a használó, tud új játékot kezdeni, menteni/betölteni, időt mérni, stb.

- Board, egy játékos táblája, aminek van pl. mérete, már szétlőtt mezői, hajói, stb.

- Ship, a táblák által tárolt hajók osztálya, geometriával, lehet kérdezni tőle, hogy elsüllyedt-e... (Ehhez a hajónak "ismernie" kell a hozzá tartozó táblát)

- Player, a játékos és annak adatai, statisztikái, ...

De ez csak tipp, többféle megoldás lehetséges. És ez csak a tervezés eleje, nagy vonalakban.

Nem tudom tanultál-e olyat, hogy hogyan kell megtervezni egy szoftvert, de szerintem ez lenne a legcélravezetőbb. A menet közbeni bővítéssel az a baj, hogy biztosan nem fogsz mindenre előre gondolni és akkor vagy írhatod át az egész kódbázist vagy beletörődsz, hogy onnantól kezdve csak hozzágyógyítani tudod az új részeket a programhoz, ami nem egy szép programozói gyakorlat. Ezzel szemben egy UML ábrát úgy szerkesztesz, ahogy kedved van, még az átkötözgetés sem igazán probléma (csak macerás).

Ha nem tanultál tervezést, akkor jah, írd meg az alapprogramot ahogy tudod, aztán utólag bővítsd ki. Arra ügyelj, hogy az utólagos funkciók kis dolgok legyenek, akkor talán nem kell annyit refaktorálni az eredeti kódban.

"Vicces, hogy #2 is ugyanezt írta le, és le lett pontozva"

Őszintén szólva én azt csak kb. átfutottam, nem pontoztam sehova. Nem tudom, miért lett így lehúzva, szerintem nincs benne semmi olyan durva hiba, ami indokolná.