Hogyan készítsem elő a programomat mielőtt megírom?

Ha objektumorientál programot tervezel, az első dolog átgondolni (és ha bonyolultabb program ledokumentálni,) hogy milyen "entitások" lesznek a programodban, azaz milyen fogalmakat/típusokat/dolgokat modellezel, és ezeknek milyen funkcióik lesznek - ezekből lesznek az osztályok és metódusok.

Egy torpedójátéknál én például ilyen osztályokat hoznék létre: játékos, tábla, hajótípus, hajó. A táblának lenne pl. egy olyan metódusa, ami adott x,y kordinátára megmondja annak a státuszát: üres, hajó, meglőtt üres, meglőtt hajó. A hajót úgy inicializálhatod, hogy megmondod melyik táblára kerüljön, melyik hajótípus, milyen konkrét koordinátákra. Onnan pedig meghívhatna egy metódust a hajótípus classban, ami megmondja, hogy az adott koordinátákkal, az adott táblán az valid elhelyezés-e.

Amikor oda jutsz, hogy a metódusok *hogyan* végezzék el a feladatukat, tehát a konkrét algoritmus-írásig, akkor meg a legjobb kezdés, ha átgondolod, hogy ha neked kézzel kéne elvégezni a feladatod papíron, akkor hogyan csinálnád, és elemi lépésekre bontod a folyamatot. Ha bonyolult a folyamat ezt is lejegyezheted pszeudokódként, vagy folyamatábraként mielőtt kódolni kezdesz.

A konkrét problémához annyi segítség, hogy először össze kéne gyűjteni minden egyes kordinátáját egy hajónak, és együtt vizsgálni őket mielőtt lerakod a hajót, mert ha darabonként rakod le a táblára, de sehol nem tárolod, hogy melyik darab melyik hajóhoz tartozik, akkor két egymás melletti hajóról már meg sem fogod tudni mondani, hogy hol kezdődik az egyik, és hol ér véget a másik.

Nem olvastam el a kódot mert késő van és kígyóban régen olvastam/írtam de ha nagyobb projektbe kezdesz bele soha ne csak programozz, először tervezd meg legalább mondati szinten hogy minek kéne történni milyen sorrendben, segíthet hiba megtalálásában is és fejtsd ki az egyes sima lépéseket hogyan kéne kinézniük és azt írd meg

Példának (most a kódod nélkül ahogy emlékszem a torpedóra)

Lekell raknod a hajóidat kezdésnek, ezt találd ki hogy a legjobb bekérni a felhasználótól de szerintem pl bekéred a két koordinátát, hajó hosszát és melyik irányba nézzen

és akkor ezeket kifejted (papíron vagy akárhol hogy később ránézhess)

Hogy néz ki a koordináta? Egy szám 0-9ig meg egy betű A-J között (bekéred az adatot, if-el megnézed hogy az ASCII alapján beleesnek e) ha jó az adat továbblépsz ha nem (else) megmondod a felhasználónak hogy buta (talán ne) ezután ha jó koordinátát adott meg kiválaszt egy hajót (nevezd el őket vagy szám a hosszukra stb) de mondjuk az anyahajót akarom lerakni ami asszem 5 hosszú (megnézed még nem rakott le 1 anyahajót) és bekéred merre nézzen fel le balra jobbra, ha beadja hogy balra akkor egy ciklussal mondjuk lefuttathatod hogy a megadott koordináta és attól 4re balra üres (és hogy nem menne e a koordináta 0 alá mert akkor kimenne a mapról) akkor lerakod a hajót és visszadob az elejére amíg van hajód (while ciklus pl egy shipcounttal)

Lehet picit túl command lineosan gondolom ezt át de csak példa

a pálya persze egy 2D vektor lenne ahol minden mező 1 lenne kezdésnek, és erre alakíthatsz ki egy jó rendszert hogy hogyan kövesd hol mi van az én ötletem mondjuk hogy a hajó hossza jelzi a számát a vektorban (a 2 hosszú hajó kettő egymás melletti 2es jelezné, de elkell tárolnod melyik hajónak melyik koordinátái tartoznak hozzá) és ez felmenne 5ig

a játéknál meg megadsz egy koordinátát és oda lősz ahova lősz arra a koordinátára hozzáadsz 5öt így jól tudod követni hova lőttek

1 = nem lőttek és nincs hajó

2-5 = hajó

6 = nincs hajó de már lőttek ide

7-10 = van hajó és már lőttek ide

(ezért nem 0val töltöttek fel a vektort mert így az eltolás könnyebb)

és ez már vizuálisan is kiírható egy ciklussal

Remélem segített az így majdnem hajnali 4kori felfogásom ha kérdeznél nyugodtan, segítek ahogy tudok de én C#ot tudok inkább

A kódot még nem nézem meg, a leírtakra reagálnék: A probléma valószínűleg az, hogy még a Python nyelvet sem ismered, de már rögtön OOP próbálsz programozni benne.

Minden programot úgy célszerű írni, hogy az egyszerűbbtől haladunk a bonyolultabb felé. OOP esetében ez azt jelentené, hogy először csak lemodellezed a játékot papíron, hogy milyen lehetőségek vannak a játékban, hogyan zajlik maga a játék, stb., majd ebből kiokoskodod, hogy milyen függvények, adattagok, objektumok kellenek a megvalósításához. Nem tudom érezhető-e, de még egy sor kód leírásáig sem jutottunk el.

Na most, ha nincsen OOP tapasztalatod, akkor én azt mondanám, hogy inkább hagyományosan oldd meg a játékot, sőt ne is a teljes játékot, csak egy-egy kis részét. Az építész sem rögtön egy felhőkarcolót tervez meg.

Ha mégis ragaszkodsz az OOP-hoz és a jelenlegi kódhoz, akkor tűzz ki egy kisebb célt, pl. elég, ha csak adott teszt esetre működik a kód, nem muszáj, hogy rögtön egy éles használatra szánt játékprogramot írj.

(( Most megyek és ránézek a kódra.))

Elsőnek mindig tervezni kell. Főleg OOP-nél.

Írd le mit szeretnél nagy vonalakban. Táblázatokba rendszerezed. Csinálj használati eset diagramokat, tevékenységi diagramokat, állapotgép diagramot. Ha adatbázist is használnálnál akkor elengedhetetlen, hogy az Egyed-Kapcsolat-ot megcsináld, illetve Entity Framework. Ha ezeket mindet megcsináltad és szépen végigmentél a szoftvertervezés alapvető lépésein, utána már lekódolni pár perc. Egy jól megtervezett szoftver, főleg hogyha a tevékenységi diagramok megvannak akkor tényleg nagyon gyors a kódolás.

ma 16:01

Azért amit lekódolni pár perc azt nem fogod tervezgetni, nem kell túlzásokba esni.

ma 18:51

Ez nem így működik.

ma 21:46

Melyiken? Mert ahol én végeztem nem mondtak ilyet.

Gondolom a windows 10-et is csak úgy 1-2 perc alatt összedobták miután csináltak egy róla egy használati eset diagrammot.

Gondolom az iteratív fejlesztést se tanítják már egyetemen? A változó igényeket?

Biztos az a sok apró program amit írtam cégeknek is kuka mert 1 óra munkát nem terveztem előtte napokig.