Функции верхнего уровня Kotlin против функции объекта

Question

У меня есть статическая функция, которая ограничена некоторым контекстом, например, только для документов.Есть 2 альтернативных способа определить его как функцию или функцию верхнего уровня в объекте.

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()
}

Преимуществофункция верхнего уровня в том, что она не обернута в объект, и недостаток в том, что к ней можно получить доступ из любого места без префикса имени класса.Есть ли преимущества или недостатки или лучшая практика для таких случаев?

Answer 1

Подсказка для многомодульных проектов:

Используйте модификатор видимости internal для выделения функции верхнего уровня содержащему ее модулю, чтобы она не загрязняла автозаполнение IDE внесвязанные модули.

// 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

Answer 2

KotlinConf 2017 - Вы можете, но должны ли вы?Майк Гоулин рекомендует использовать осторожно функцию верхнего уровня 1006 *, поскольку это может привести к "автозаполнению загрязнения".

Но, кстати, Андрей Бреслав считал, чтоФункция уровня как его самая любимая языковая функция в KotlinConf 2018 - Закрывающая панель.

Answer 3

Рекомендуется никогда не использовать объект для создания пространств имен и всегда использовать объявления верхнего уровня, когда это возможно.Мы не нашли конфликтов имен, чтобы быть проблемой, и если у вас есть конфликт, вы можете решить его, используя импорт с псевдонимом.

Answer 4

Хотя рекомендуемый подход заключается в использовании объявлений верхнего уровня, когда это возможно, функции, которые используются только в определенных контекстах , должны быть ограничены этим контекстом и объявлены в релевантном классе.Функции верхнего уровня особенно полезны для определения вспомогательных или служебных функций.Примером могут служить функции коллекций в стандартной библиотеке Java, которые имеют действительно глобальную область видимости.То же относится и к константам.Прочитайте обсуждение под этим ответом https://stackoverflow.com/a/48820895/1635488

В вашем случае DocPrefManager имеет определенный контекст.Кроме того, я думаю, вы не хотите загрязнять список автозаполнения IDE конкретными функциями.Это приводит к невозможности обслуживания.

PS DocPrefManager функции не должны зависеть от App.getContext ().DocPrefManager класс должен быть инициализирован с контекстом, и в этом случае использование функций верхнего уровня является странным, потому что ваши функции не будут статичными.

Answer 5

object Clazz будет скомпилировано как одноэлементное, функция верхнего уровня будет скомпилирована как статическая в JVM.

, если нет причин для использования вашего метода в качестве статического (верхнего уровня, компаньонобъект) путь будет немного высокопроизводительным. (ref: https://stackoverflow.com/a/11993118/5354658)