Kuidas te suhtute väga pikkadesse klassidesse, mis sisaldavad 2000 kuni 4000 rida koodi?

Negatiivne.

Pikkade klasside rikkumine üksikvastutuse põhimõttest (SRP) ja vähim teadmiste põhimõttest (Principle of Least Knowledge). See põhjustab järgmisi probleeme:

• Raskesti loetav ja mõistetav: Suur koodimahut raskendab klassi loogika mõistmist.
• Raskesti hooldatav ja muudetav: Klassiosa muutmine võib tahtmatult mõjutada teisi osi, põhjustades vigu.
• Koodide duplitseerimise risk: Funktsionaalsus võib korrata klassi erinevates osades.
• Testimise probleemid: Suure klassi üksustestid muutuvad keeruliseks ja aeganõudvaks.
• Taaskasutusvõimaluste vähenemine: Osade funktsionaalsuse eraldamine ja kasutamine mujal on keeruline.

Ideaalis peaksid klassid olema lühikesed ja täitma ühte konkreetset ülesannet. Funktsionaalsus tuleks jagada väiksemateks, spetsialiseeritud klassideks või funktsioonideks. Selliste "jumalate" klasside refaktorimine on prioriteet koodibaasi kvaliteedi parandamiseks.

Jagamiseks saab kasutada järgmisi lähenemisviise:

• Seotud loogika eraldamine eraldi klassidesse: Näiteks andmete haldamine, UI-loogika, äriloogika.
• Disainimustrite rakendamine: MVC, MVP, MVVM, Repository, Factory jmt.
• Jagamine väiksemateks funktsioonide/methodideks: iga meetod peaks tegema ühe asja.
• Kasutades Kotlinis laiendusi (extensions): funktsionaalsuse lisamiseks ilma algklassit muutmata.