Зачем переопределять метод toString в дата классе Kotlin

Что проверяют

Знаете ли вы, что у data class этот метод уже сгенерирован, и понимаете ли, зачем его всё-таки переопределяют.

Как отвечать

Начните с уточнения: у data class компилятор сам генерирует toString, equals, hashCode, copy и функции разложения. Сгенерированный вывод содержит имя класса и все свойства основного конструктора.

Отсюда причины переопределять его вручную:

• чувствительные данные. Это главная причина. Модель с токеном, паролем, номером карты или персональными данными попадёт в лог целиком, потому что кто-нибудь напишет log.d(TAG, "$user"). Переопределённый toString маскирует такие поля;
• слишком много данных: модель с описанием вакансии на несколько килобайт засоряет логи, и в выводе оставляют только идентификатор и ключевые поля;
• свойства вне основного конструктора в генерируемый вывод не попадают, и если они важны для отладки, их добавляют руками;
• читаемость в отчётах об ошибках и в сообщениях тестов.

data class Session(val userId: String, val token: String) {
    override fun toString() = "Session(userId=$userId, token=***)"
}

Полезно добавить смежное: equals и hashCode тоже считаются только по свойствам основного конструктора, и это регулярно удивляет. А для сокрытия полей есть и другой подход, когда чувствительное значение оборачивают в отдельный тип со своим toString, и тогда защита работает везде, где это значение появляется.

Где спотыкаются

Говорят, что без переопределения будет имя класса и хеш. Это верно для обычного класса, но не для data class.

Логируют модели целиком и утекают токены в систему сбора логов.

Ждут, что в выводе окажутся свойства, объявленные в теле класса.