Статическая переменная для управления состоянием - PullRequest
0 голосов
/ 11 октября 2018

У меня проблемы с пониманием проблемы в этом сценарии.

У меня есть класс, используемый для отслеживания Google Analytics, давайте назовем его FlurryTracker, у него есть 2 метода StartTrackingScreen(ScreenName) и StopTrackingScreen().

Теперь, если у меня есть статическая переменная с именем screenName, и каждый раз, когда экран отслеживания запуска вызывается, screenName переназначается.

startTrackingScreen(activity: Activity, screen: DhTracker.Screen<T>) {
        screenName = screen.getName()
        val lastScreen = Singleton.getLastScreen()
        //If last screen is not same as current screen

            FlurryAgent.logEvent(screenName, true)

    }
}


override fun stopTrackingScreen() {
    //New screen will start tracking before lastScreen tracking is stopped.
    if (enabled) {
        FlurryAgent.endTimedEvent(Singleton.getLastScreen()?.getName())
    }
}

companion object{
  lateinit var screenName : String
}

Эти методы вызываются в onStart() и onStop() в самом приложении.

Итак, с учетом сказанного, мы отслеживаем только 1 экран за раз, потому что когда пользователь переходит на новый экран, будут вызываться onStop() и onStart().

Таким образом, несмотря на то, что screenName является статическим, каждый раз при вызове методов жизненного цикла эта статическая переменная переопределяется.Поскольку на телефоне не может быть запущено 2 актива одновременно, одновременно будет активен только 1 экземпляр моего трекера.

Я не вижу здесь проблемы с использованием статики, хотяЯ знаю, что лучшие практики говорят, что screenName должно создаваться с каждым новым экземпляром.Я смотрю на это неправильно?

1 Ответ

0 голосов
/ 11 октября 2018

Вы можете сделать это.

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

Недостатки для статического класса:

  • Сложно проверить из-за того, что вам необходимо заменить статический метод
  • Трудно создать второй экземпляр
  • Трудно передать, если вы решите, что хотите (Некоторые люди хотели бы знать, какие классы используются данным путем для целей тестирования)

Это не так уж плохо, вы можете жить с ними - однако ни одна из этих проблем не существует, если вы используете синглтон.Вы можете легко передать его, изменить его поведение, преобразовать его для использования инъекции вместо шаблона синглтона,…

Так что я не могу придумать причину, чтобы когда-либо использовать статический подход, не так ли?никаких преимуществ.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...