Kotlin Singletons: Объект против Класса с приватным конструктором

Question

Пример приложения sunflower от Google использует закрытый класс с сопутствующим объектом для реализации шаблона Singleton своего хранилища вместо простой реализации хранилища в качестве (по сути Singleton) объекта.

Впервые я увидел, как Синглтон реализовал этот способ в Kotlin вместо того, чтобы реализовывать его как Объект.В каком контексте (ах) следует использовать эту реализацию частного конструктора вместо более распространенной реализации Object?

class GardenPlantingRepository private constructor(
  private val gardenPlantingDao: GardenPlantingDao
) {
  suspend fun createGardenPlanting(plantId: String) {
    withContext(IO) {
      val gardenPlanting = GardenPlanting(plantId)
      gardenPlantingDao.insertGardenPlanting(gardenPlanting)
    }
  }

  suspend fun removeGardenPlanting(gardenPlanting: GardenPlanting) {
    withContext(IO) {
      gardenPlantingDao.deleteGardenPlanting(gardenPlanting)
    }
  }

  fun getGardenPlantingForPlant(plantId: String) =

    gardenPlantingDao.getGardenPlantingForPlant(plantId)

  fun getGardenPlantings() = gardenPlantingDao.getGardenPlantings()

  fun getPlantAndGardenPlantings() = gardenPlantingDao.getPlantAndGardenPlantings()

  companion object {
    // For Singleton instantiation
    @Volatile private var instance: GardenPlantingRepository? = null

    fun getInstance(gardenPlantingDao: GardenPlantingDao) =
      instance ?: synchronized(this) {
        instance ?: GardenPlantingRepository(gardenPlantingDao).also { instance = it }
      }
  }
}

Answer 1

Использование object является проблемой, если вашему одноэлементному экземпляру нужны параметры, как в данном случае здесь, с GardenPlantingDao, поскольку они не могут принимать аргументы конструктора.Это часто встречается на Android, так как во многих случаях для работы синглетам требуется Context.

Вы могли бы по-прежнему использовать object в этих случаях, но это либонебезопасно или неудобно:

• Первым вариантом было бы предоставить ему его зависимости с использованием метода установки перед использованием любого из его других методов.Это будет означать, что любой другой метод должен будет проверять, инициализированы ли зависимости, и, возможно, генерировать исключения, если они этого не делают, что приводит к проблемам во время выполнения.
• В качестве альтернативы, вы можете требовать любые зависимости в качестве аргументовк каждому методу синглтона, который утомителен на сайте вызовов.

Отсюда и «традиционный» способ реализации синглтона с помощью частного конструктора и метода фабрики.