Kaip jaučiatės apie labai ilgus klases, kurios turi nuo 2 iki 4 tūkstančių eilutės kodo?

Neigiamai.

Ilgos klasės pažeidžia vienos atsakomybės principą (SRP) ir mažiausios žinios principą (Principle of Least Knowledge). Tai sukelia šias problemas:

• Sunku skaityti ir suprasti: Didelis kodo kiekis apsunkina klasės logikos suvokimą.
• Sunku prižiūrėti ir keisti: Pakeitus vieną klasės dalį, gali netyčia paveikti kitas, sukeldamas klaidas.
• Kodo dubliavimosi rizika: Funkcionalumas gali kartotis skirtingose klasės dalyse.
• Testavimo problemos: Didelės klasės vienetinio testavimo procesas tampa sudėtingas ir užima daug laiko.
• Pakartotinio naudojimo galimybės sumažėjimas: Sunku išskirti ir naudoti funkcionalumo dalis kitur.

Idealiu atveju, klasės turėtų būti trumpi ir atlikti vieną konkretų uždavinį. Funkcionalumas turėtų būti suskirstytas į mažesnes, specializuotas klases ar funkcijas. Tokių "dieviškų" klasių refaktorizavimas yra prioritetas, siekiant pagerinti kodo kokybę.

Šiam tikslui galima naudoti šiuos požiūrius:

• Susijusios logikos išskyrimas į atskiras klases: Pvz., duomenų valdymas, UI logika, verslo logika.
• Dizaino šablonų taikymas: MVC, MVP, MVVM, Repository, Factory ir kt.
• Skirstymas į mažesnes funkcijas/metodus: kiekvienas metodas turėtų atlikti vieną dalyką.
• Kotlin plėtinių (extensions) naudojimas: funkcionalumo pridėjimui be originalios klasės keitimo.