Kotlin позволяет назвать функцию так же, как существующий класс, например. HashSet с функцией инициализации можно реализовать так:
fun <T> HashSet(n : Int, fn: (Int) -> T) = HashSet<T>(n).apply {
repeat(n) {
add(fn(it))
}
}
При использовании он выглядит как обычный конструктор HashSet:
var real = HashSet<String>()
var fake = HashSet(5) { "Element $it" }
Следует ли этого избегать или поощрять и почему?
UPD
В обновленных соглашениях о кодировании есть раздел по этой теме. :
Заводские функции
Если вы объявляете фабричную функцию для класса, не давайте ей то же имя, что и сам класс. Лучше использовать отдельное имя, чтобы было понятно, почему поведение фабричной функции особенное. Только если особой семантики действительно нет, можно использовать то же имя, что и у класса.
Пример:
class Point(val x: Double, val y: Double) { companion object { fun fromPolar(angle: Double, radius: Double) = Point(...) } }
Тем не менее, мотивация, которую я описал ниже, кажется, по-прежнему актуальна.
Как сказано в документации по стилю именования:
Если вы сомневаетесь, по умолчанию используйте соглашения о кодировании Java, такие как:
- методы и свойства начинаются с нижнего регистра
Одной из веских причин избегать имен функций, идентичных классу, является то, что это может запутать разработчика, который будет использовать его позже, потому что, вопреки их ожиданиям:
open)new HashSet(n, it -> "Element " + it) — ошибка)HashSet(n) { "Element $it" } создаст не HashSet, а, например, LinkedHashSetЛучше явно показать, что это фабричная функция, а не конструктор, чтобы избежать путаницы.
В stdlib также обычно избегают именования функции, аналогичной классу. Учитывая SomeClass, в stdlib предпочтительным стилем именования для фабричных функций является someClassOf, someClassBy или что-то еще, что лучше всего объясняет семантику функции. Примеры:
generateSequence { ... } и sequenceOf(...)lazy { ... } и lazyOf(...)compareBy { ... }listOf(...), setOf(...), mapOf(...)Таким образом, у человека определенно должны быть веские причины для того, чтобы функция имитировала конструктор.
Вместо этого имя функции может рассказать пользователю больше (даже обо всем) о ее использовании.
Я согласен с горячей клавишей +. Вероятно, в этом случае лучше избегать путаницы.
Если он используется только внутри и все остальные разработчики (если таковые имеются) согласны с этим, я бы сказал, что нужно пойти на это. Python признает эту идею, и мне она нравится. Черт возьми, они идут в обоих направлениях, и вы тоже можете называть класс в функциональном регистре, если это больше похоже на то, что он действует как функция. Но Python не должен иметь дело с взаимодействием Java, поэтому определенно не делайте этого для общедоступного кода.
