Kā jūtaties par ļoti garām klasēm, kas satur no 2 līdz 4 tūkstošiem rindu koda?

Negatīvi.

Ilgas klases pārkāpj vienas atbildības principu (SRP) un mazākās zināšanas principu (Principle of Least Knowledge). Tas noved pie šādām problēmām:

• Grūti lasīt un saprast: Liels koda apjoms apgrūtina klases loģikas uztveri.
• Grūti uzturēt un mainīt: Izmaiņas vienā klases daļā var nejauši ietekmēt citas, radot kļūdas.
• Koda dublēšanās risks: Funkcionalitāte var atkārtoties dažādās klases daļās.
• Testēšanas problēmas: Liela klases vienības tests kļūst sarežģīts un laikietilpīgs.
• Atkārtotas izmantošanas iespēju samazināšanās: Ir grūti izvilkt un izmantot funkcionalitātes daļas citur.

Ideālā gadījumā, klases būtu īsas un veiktu vienu konkrētu uzdevumu. Funkcionalitāte būtu sadalāma mazākās, specializētās klasēs vai funkcijās. Šādu "dievišķo" klasu refaktorizācija ir prioritāte, lai uzlabotu koda kvalitāti.

Decompozīcijai var izmantot šādus pieejas:

• Saistītās loģikas atdalīšana atsevišķās klasēs: Piemēram, datu pārvaldība, UI loģika, biznesa loģika.
• Dizaina modeļu piemērošana: MVC, MVP, MVVM, Repository, Factory utt.
• Sadalīšana mazākās funkcijās/metodēs: katra metode būtu jāveic viena lieta.
• Kotlin paplašinājumu (extensions) izmantošana: funkcionalitātes pievienošanai bez oriģinālās klases modificēšanas.