Hello. Is it possible to split the class file into separate files, something like include in Android .xml or make an inner class as a separate file?
1 Like
No it’s not possible atm and I don’t know of any plans to add this.
What would be the point of that?
Nested/inner/local classes are already compiled to separate .class files (usually with $ signs in the name, which isn’t otherwise legal). But other than that, how could you split a class up into parts that would make any sense on their own?
The one thing I can think of is using kapt to add real member functions to your classes. That way you could generate interface implementations. Not sure why else you would want that.
Are we talking about the generated .class files (bytecode result for jvm) or about the kotlin .kt files? I was thinking about the .kt files when I answered, but there isn’t any way to split the .class files right now but you can’t split .class files appart from the automatic splitting for classes like @gidds mentioned.
I assume you are asking for something similar to C# partial classes . There are already two threads on this topic:
1 Like
It’s about splitting .kt files. If they become too big ( > 2000 strings), IDE’s code inspections performs slow. Also it could be possible to separate some code blocks like in feature toggle.
So, inheritance is a not full case solution because there is no multiple inheritance;
inline is not fine because there are a lot of dependencies and inline classes I found possible to use in the same file only.
Why do you have a class that is >2000 lines long. This sounds like a problem in your architecture.
Some Android fragments can be big and a common practice is to use one .kt / .java file for a whole screen.
2k lines is definitely a huge codesmell of poor design. You should be able to split that large class up into chunks of other things more cohesively with a better design. DSLs aren’t an exception either.
I would recommend taking a close look at all of your files over 500 lines (which is on the larger side of a reasonable limit IMHO) and seeing if there’s really multiple reasons it might need to be changed (SOLID principal of “single responsibility”). I
If you have files over 500 lines with multiple hidden classes mixed together then there’s a good chance you have functions over 30-40 lines. Those you should consider refactoring as well.
I recommend the book Clean Code by Robert Martin (Uncle Bob). He’s a better advocate for this stuff than me.
DSLs often require more lines than normal for readability. Still, even if they don’t aways fall into the guide of function size being 20 lines or less, the real guide for sizing functions does apply: which responds to the question of “how big should functions be?” with “Smaller… No, smaller than that!”
If your function is too large it’s probably doing more than one thing (another golden rule of functions: they should do only one thing). DSLs can suffer from a “YAML like explosion” of configuration. But unlike YAM, a DSL can be refactored with functions that apply a group of cohesive configuration with a single method call.
The large file use case isn’t a motivating use case for allowing partial classes since the goal for breaking the restriction is to support something that would normally be considered a code smell–or worse, hide the code smell across multiple files so it’s harder to detect.
1 Like
I decided to try to split the class by separating its features and moving them in different modules. Should be a good solution for a feature toggle.
1 Like