OOP-ben miért kell a minél szűkebb (lehetőleg privát) láthatóságra törekedni? Milyen veszélyforrásokat rejt magában, ha nem teszünk így?

Amihez nem férnek hozzá kívülről, azt nem is lehet elrontani kívülről. A te kis programrészednek a működését ismered, készítsd fel minden lehetséges interakcióra, és akkor nem fog hibás működést mutatni.

Veszélyforrás: kusza kód, összeakadnak különböző függvények/változók, rosszul hívják meg a függvényeit, stb.

Kicsi, zárt, önálló függvényekre és osztályokra van szükség! Az átláthatóságra kell törekedni! Iskolai feleadatokból persze ennek a haszna nem látszik, de egy több millió soros kódbázist átalakítani, vagy hibát keresni benne nagyságrendekkel nehezebb, ha nem egyértelmű első ránézésre, hogy melyik osztály/függvény mit csinál és mihez van hozzáfáráse. Nagyobb kódbázisokat rendszerint 5 évente újra szoktak írni olyan helyeken, ahol nem tartják be a clean code szabályokat. Egyszerűen a sok globális/publikus változó, a túl nagyra nőtt osztályok, programon keresztül-kasul lövöldözgetett delegate-ek olyan spagetti kódot eredményeznek, amin nincs élő ember, aki kiigazodik. Ilyenkor kikukázzák az egészet és kezdik előlről. Ez a rossz programozók és rossz munkahelyek ismertetőjegye.

Ügyelni kell még olyan dolgokra is, hogy:

Egy osztály/függvény csak egy bizonyos dologgal foglalkozzon.

Ne használjunk sehol se rövidítéseket, minden változó/függvény/osztály nevéből derüljön ki, hogy az mit csinál.

Lehetőségekhez mérten minden ismétlődő kódblokkot próbáljunk kiváltani egy hívható függvénnyel.

A kód mondatszerűen olvasható legyen. Csak azt a kód sort lássuk el kommentel, amiből nem látszik egyértelműen, hogy mit csinál.

Nyelvtől függően minden változó/property alapértelmezetten readonly, const, getter ... már azzal sok fejfájást meg tudunk spórolni ha törekedünk arra, hogy minden változó inicializáláskor kapjon csak értéket és később nem változhat az értéke.

A programozás főként csapatmunka. A kódodnak mások számára is könnyen érthetőnek kell lennie és az x évvel későbbi önmagad számára is, ha át kell írnod!

pl van a player. Health adattag és ha nem tervezek ezen az értékadáson biztonsági műveletet végrehajtani akkor felesleges hogy egy propertyn vagy metódus on keresztül történjen az értékadása ekkor lehet publikus nyugodtan.

A névütközés meg nem történhet mert player.Health és enemy.Health nem ugyanaz.

De kérdező ha nem rakod metódusban, ropertybe akkor ez a változó olyan értékeket is felvehet majd amilyet nem akarsz. Pl automatikusan növeled az életét egy ellenségnek másodpercenként 0.5 tel mert regenerálódik folyamatosan így ha nem kezeled le propertyben vagy metódusban azt hogy enemy. Health nagyobb e mint maxhealth akkor olyan nagyra nőhet az élete hogy képtelenség lesz megölni.

De ugye még mindig csinálhatsz olyat hogy előtte ellenőrzöd hogy kisebb e mint maxhealth és akkor továbbra is használhatod függvény nélkül és így is jó lesz de az ilyesfajta megoldások nehezen átláthatóvá teszik a kódot plusz logikátlanabb felépítésű lesz így ahogy egyre csak nagyobb lesz a progi úgy lesz egyre nehezebben karbantartható, újraértelmezhetőbb és átláthatatlanabb.