Hoe sta je tegenover zeer lange klassen die tussen de 2.000 en 4.000 regels code bevatten?

Negatief.

Lange klassen schenden het Single Responsibility Principle (SRP) en het Principle of Least Knowledge. Dit leidt tot de volgende problemen:

• Moeilijk te lezen en te begrijpen: Een grote hoeveelheid code bemoeilijkt het begrijpen van de logica van de klasse.
• Moeilijk te onderhouden en te wijzigen: Het wijzigen van een deel van de klasse kan onbedoeld andere delen beïnvloeden, wat fouten veroorzaakt.
• Risico op code duplicatie: Functionaliteit kan zich herhalen in verschillende delen van de klasse.
• Problemen met testen: Unit-testen van een grote klasse worden complex en tijdrovend.
• Verminderde herbruikbaarheid: Het is moeilijk om delen van functionaliteit te extraheren en elders te gebruiken.

Ideaal gezien moeten klassen kort zijn en één specifieke taak uitvoeren. Functionaliteit moet worden opgesplitst in kleinere, gespecialiseerde klassen of functies. Het refactoren van zulke "goddelijke" klassen is een prioriteit om de kwaliteit van de codebasis te verbeteren.

Voor decompositie kunnen de volgende benaderingen worden gebruikt:

• Verwijder gerelateerde logica naar aparte klassen: Bijvoorbeeld gegevensbeheer, UI-logica, bedrijfslogica.
• Toepassen van ontwerp patronen: MVC, MVP, MVVM, Repository, Factory, enz.
• Opsplitsen in kleinere functies/methoden: elke methode moet één ding doen.
• Gebruik maken van extensies in Kotlin: om functionaliteit toe te voegen zonder de originele klasse te wijzigen.