I have static function which is limited to some context eg only for docs. There are 2 alternative ways to define it as top-level function or function in an object.
1.
package com.armsoft.mtrade.data.pref
import com.armsoft.mtrade.App
import com.armsoft.mtrade.domain.model.DocSaveType
object DocPrefManager {
private const val DOC_PREF = "DOC_PREF"
private const val KEY_ORDER_SAVE_TYPE = "KEY_ORDER_SAVE_TYPE"
@JvmStatic
fun setOrderSaveType(orderSaveType: DocSaveType) {
val context = App.getContext()
val sharedPreferences = context.getSharedPreferences(DOC_PREF, 0)
val editor = sharedPreferences.edit()
editor.putString(KEY_ORDER_SAVE_TYPE, orderSaveType.getCode())
editor.commit()
}
}
2.
package com.armsoft.mtrade.data.pref
import com.armsoft.mtrade.App
import com.armsoft.mtrade.domain.model.DocSaveType
fun setOrderSaveType(orderSaveType: DocSaveType) {
val context = App.getContext()
val sharedPreferences = context.getSharedPreferences(DocPrefManager.DOC_PREF, 0)
val editor = sharedPreferences.edit()
editor.putString(DocPrefManager.KEY_ORDER_SAVE_TYPE, orderSaveType.getCode())
editor.commit()
}
The advantage of top-level function that it is not wrapped in an object and disadvantage that it can be accessed from everywhere without class name prefix. Are there advantages or disadvantages or best practice for such cases?
Tip for multi-module projects:
Use the
internalvisibility modifier to scope a top-level function to its containing module so that it doesn't pollute the IDE auto-complete in unrelated modules.
// module A
internal fun doSomething() {
// ...
}
// module B
doSomething() // (!) Cannot access 'doSomething': it is internal in module A
// Does NOT show up in module B's auto-complete
KotlinConf 2017 - You Can, but Should You? by Mike Gouline recommends we should use the top-level function carefully because it may cause "autocomplete pollution".
But, BTW, Andrey Breslav regarded the top-level function as his the most favorite language feature in KotlinConf 2018 - Closing Panel.