import and aliasing practice

Viewed 3655

Currently following Leiva's "Kotlin for Android Developers" book, and there was one thing I was wondering about ...

import blah.data.Forecast
import blah.domain.Forecast as ModelForecast

Why create a "Forecast" class in each, the data and the domain layer, and then alias one? Why not simply name the domain one blah.domain.ModelForecast to begin with?

I generally try to avoid identical names in my own project, even when the classes do happen to end up in different packages. What benefit do I get from not doing so?

1 Answers

You're right, but maybe you don't have rights to change names of imported classes. For example, imagine you import different Date classes from java package:

import java.util.Date
import java.sql.Date as SqlDate

In such cases the aliasing is a great tool Kotlin provides.

Related