Ez szerintetek mennyire jo megoldas php-ban?

Nézz utána: Transaction, ha már "utalás", mert mivan akkor ha egyikről levontad, de nem kerül át a másikra egy hiba miatt?

Example: [link]

"Es igy az osszes feladatra irnek egy fuggvenyt, mennyire jo megoldas?"

Bocs, de ez semennyire se jó megoldás.

Ha OOP-ben jártas vagy, akkor nézz utána olyan dolgoknak, mint pl. a SOLID, MVC/MVP/MVVP, meg a dependency injection. Adok is ehhez egy forrást: [link]

És nézegess olyan forráskódokat, amik követik a SOLID elveket. Pl. a Slim 4 kódja ebből a szempontból szerintem elég jó: [link]

Szépen névterekbe van szervezve az egész, és jól látszik az is, hogy egy-egy interface-nek vagy osztálynak milyen felelősségei vannak: [link]

"az osszes sajat fuggvenyt egy fuggveny.php fajba kitenni"

Mert az ilyen megoldásokból alakulnak ki a karbantarthatatlan, kezelhetetlen, tesztelhetetlen kódok.

"Lesz egy olyan fajl,hogy bank.php amiben ugye lesz egy adabzais csatlakozas(meghivva) kiiratom az adott felhasznalo egyenleget, nevet."

Ez úgy szokott kinézni, hogy első héten megírod a bank.php-t, ami csatlakozik az adatbázishoz és kiírja a felhasználó egyenlegét, nevét. Két nap múlva rájössz, hogy nem csak a bank.php-nak kellene kiírnia ezeket a dolgokat, hanem mondjuk máshol is meg kellene jeleníteni, és akkor átírod a bank.php-t úgy, hogy csak visszaadja az adatokat, de ne jelenítse meg, és írsz mellé egy megjelenítőt.

Három nap múlva rájössz, hogy nem csak forintban szeretnéd megjeleníteni az egyenleget, hanem tetszőleges formátumban, ezért megint átírod a bank.php-t, hogy úgy adott formátumban adja vissza az adatokat.

Két nap múlva eszedbe jut, hogy jó lenne, ha mondjuk nem csak adatbázisból tudna olvasni a bank.php, hanem mondjuk fájlból is vagy más típusú adatbázisból, ekkor megint átírod, és ezekkel az átírásokkal együtt valószínűleg át kell írni egy rakat másik fájlt, ami a bank.php-tól függ.

De ha eleve megpróbálsz valamilyen MVC vagy MVP modellre törekedni, akkor egy csomó kört megspórolsz magadnak. Mondjuk a bank.php helyett lesz egy osztályod, ami az adott felhasználó bankszámlájának adattárolóját reprezentálja, mittudomén, az Account névtérben az AccountModel osztály, ami csak a számlával kapcsolatos alapvetű műveleteket kezeli (számlaadatokat olvasás és beállítása). Hogy hol tárolja a számla adatait (adatbázisból, fájlból, stb.), az már az ő dolga. Az alapvető CRUD műveleteket implementáld le első körben.

Aztán lesz hozzá egy AccountController osztályod, ami kezeli a számlával kapcsolatos műveleteket, pl. új számla létrehozása, számlaegyenleg megjelenítése kért formátumban, stb. A felhasználótól megkapja az adatokat, és az alapján létrehozza a számlát, majd ezután, ha a felhasználó adatokat akar látni a számlájáról vagy műveleteket akar végezni vele, akkor ezeket az AccountController elintézi, illetve az AccountModel által visszaadott adatokat átkonvertálja a megfelelő formátumban.

Aztán lehet még egy view réteg, ami csak megjeleníti az adatokat és ami közvetlenül kommunikál a felhasználóval. Kirakja a formok megfelelő mezőibe az adatokat, gombok eseményeit kezeli, meghívja a controller megfelelő metódusait...

Én valahogy így csinálnám ezt, persze előtte érdemes alaposan átgondolni. Nekem szokásom UML diagramokat meg mindmapokat rajzolgatni, ha elég részletesen csinálja az ember, már ott letisztázódik nagyon sok minden, és nem a nyolcadik osztály implementálásának kellős közepén derül ki, hogy hoppá, ezt így nem is fog működni, mert.....