( _Franko_ | 2018. 01. 03., sze – 13:38 )

"Ezt már nem feltétlen kell szétszedni, így is elfogadható."

Nem "feltétlenül"? Most akkor vannak szabályok vagy rugalmas a dolog?

"Azonban lehet még "szebbé" tenni, aminek szintén vannak előnyei, hátrányai."

Ezt se sikerült hiba nélkül implementálnod, ez a kód nem azt csinálja, amit kellene... :/

Ráadásul:

"- olvashatóbb, könnyebben érthető kód,"

Szétszedted egy csomó különálló helyre azt, ami amúgy egybe tartozik.
- ha meg akarom nézni, hogy hova rajzol, akkor külön meg kell néznem, mert nincs ott a szemem előtt, ott csak egy semmitmondó konstans név van.
- ha meg akarom nézni, hogy milyen feltételek mentén rajzol, akkor külön meg kell néznem egy külön függvényben.
- ha meg akarom nézni, hogy milyen állapotok vannak, meg kell néznem a "state" értékkészletét.

"- könnyebben módosítható,"

Ha változik a "fortified" pozíciója és csak azé, akkor miért lesz könnyebben módosítható? Behoztál egy csomó plusz sort, konstanst és függvényt, amelyeket külön karban kell tartani.

"- könnyebben újrafelhasználható -> kevesebb duplikáció"

Soha nem lesz újra felhasználva, szóval nem érdekel a passzív duplikáció, hogy messziről hasonlít-e egy másik kódrészletre.

"- jobban látható az üzleti logika,"

Úgy, hogy szétszedted több helyre és nem látod egyben?

"- könnyebben optimalizálható,"

Ezzel a forrással pont optimalizációt csökkentettél, mert összevontál különálló Boolean változókat egy "state" változóba, amit aztán külön ki kell válogatni újra.

"- egy-egy rész kevesebb ok miatt változhat,"

Két éve nem változott ez a rész, ha változni fog, akkor hozzáírok egy új sort a megfelelő rétegzésbe.

"- nagyobb a kohéziója, kisebb az összefonódása (coupling),"

Oszt?

Egyébként nagyszerű példája annak, hogy mennyire káros tud lenni az erőltetett kódminőség "javítás"... elvisz egy csomó időt egy csomó látszólagos előnyért. :/