Hey guys! What's your usual take on having more th...

# announcements

[LeoColman]

Hey guys!
What's your usual take on having more than one class in the same file? I want to extract a piece of code from a complex class to a less-complex class and call it another service.
However, this class will only be used by the class I'm extracting, and I don't really want to pollute the package namespace with a class that's not useful anywhere else. Should I keep it inside the same file?

[Milan Hruban]

I definitely would.

[Perrankana]

You can check Kotlin coding conventions: https://kotlinlang.org/docs/reference/coding-conventions.html#source-file-organization

[LeoColman]

I'd usually do that as well, but I have people complaining about having 2 classes inside the same file

[LeoColman]

Placing multiple declarations (classes, top-level functions or properties) in the same Kotlin source file is encouraged

(...)

I think this sums my question up xD

[Perrankana]

hahaha yeah

[czuckie]

people often feel uncomfortable when you break from tradition, but if you’d only ever delete both types at the same time 🤷‍♂️ why not be honest and keep them together

[Casey Brooks]

I pretty much look at this in the same way I do with static inner classes in Java. I just move them to the top-level instead of keeping them inside the associated class

[LeoColman]

What about their test classes? Would you keep both test classes at the same file as well?

[Casey Brooks]

Yeah, probably. Typically, additional classes I create like this are just data classes and I don’t usually make unit tests for those

[LeoColman]

For my specific case I have a part of the main flow of a class that has way too much rules and I'll extract those rules into another smaller and testable class

[Vinicius Araujo]

A lot of people leave java, but Java doesnt leave them

[Vishnu Haridas]

I write many classes in a single file. For example, a MovieModels.kt file will contain all the model classes for Movie, other related classes, and the movie list API request and response models.