Blog: Organization is Key - Packages and Imports in Kotlin
Day 19! Today I looked at the "filing cabinet" system of Kotlin: Packages and Imports.
Beyond the Single File
As projects grow, you can't just keep everything in one place. Kotlin makes it easy to group related functions and classes into packages. But what happens when you have two classes with the same name? In Java, you'd have to use their full names (like com.a.User and com.b.User), which makes the code messy.
The Power of Aliases
Kotlin’s as keyword is a lifesaver. You can import a class and give it a local nickname.
import learn_kotlin.other.Message as OtherMessage
Now I can use Message for my local logic and OtherMessage for the one from the other package. It keeps the code readable and resolves conflicts instantly.
Batteries Included (Again)
I was surprised to learn just how many packages Kotlin imports for you by default. You never have to import kotlin.collections.List because the compiler just assumes you want it. It’s another example of how Kotlin tries to get the "boilerplate" out of your way.
Flexible Structure
One interesting fact: Kotlin doesn't force your package name to match your folder structure. While it's best to keep them aligned, this flexibility can be useful in certain multiplatform or specialized build scenarios.
Summary
Understanding packages and imports is about more than just finding files—it's about designing a clean, conflict-free namespace for your entire application.
Check out the full technical breakdown!
Comments
Post a Comment