我們是否應該避免在Kotlin中命名與現有類相同的函數？爲什麼？

Question

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" } 

這應該可以避免或鼓勵，爲什麼？

Answer 1

UPD

在更新的編碼約定，有一個section on this topic：

廠功能

如果要聲明一個類工廠功能，避免給它相同名稱作爲類本身。首選使用明確的名稱，明確爲什麼工廠功能的行爲是特殊的。只有在沒有特殊的語義時，纔可以使用與該類相同的名稱。

例子：

class Point(val x: Double, val y: Double) { 
    companion object { 
     fun fromPolar(angle: Double, radius: Double) = Point(...) 
    } 
} 

我下面所描述的動機，不過，似乎仍持有。

---

正如有關naming style文件說：

如有疑問默認的Java編碼約定，如：

• 方法和屬性開始用小寫

一個強大的理由t Ø避免命名相同的一類功能是，它可能混淆開發誰以後會使用它，因爲，違背了他們的期望：

• 功能將無法使用超級構造函數調用（如果類被open）
• 它不會通過反射
• 構造可見它不能用作Java代碼構造（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(...)

因此，人們非常需要有強有力的理由來有一個函數模仿構造函數。

相反，函數的名稱可能會告訴用戶更多（甚至是全部）關於它的用法。

Answer 2

我同意+熱鍵。在這種情況下最好避免混淆。

如果它只在內部使用，並且所有其他開發人員（如果有的話）都可以使用它，但是，我會說爲此付出努力。 Python承認這個想法，我喜歡它。哎呀，它們都是雙向的，如果你覺得它更像是一個函數，你也可以在函數的情況下命名一個類。但是，Python不必處理Java互操作，所以絕對不要爲公共代碼做這件事。