Делать статичные методы, "лишь бы не создавать экземпляр класса" - верный ли это подход?
1,00
р.
Я пытаюсь понять, как правильно писать код.
Я всегда когда это возможно, делаю статичные методы для выполнения какой либо задачи. Т.е. статичных методов довольно много.
Я не гуру и не профи Java. Я ее изучаю. Мне как то на курсах сказали, что статик методы и абстрактные классы необходимо использовать с умом.
Т.е. моя мотивация при создании статик методов, "лишь бы не создавать экземпляр класса" - верный ли это подход, если нет был бы рад получить ответ почему нет. Спасибо!
Ответ
Статические и нестатические методы отличаются (главным образом) только наличием одной вещи - контекстом. Если код суммирует два аргумента (пресловутый Math) или преобразовывает массив в список (Arrays.asList()), то ему не нужен для этого внешний контекст (состояние), и такой код, по логике, должен быть статическим. В случаях, когда вызов метода меняет состояние, и без экземпляра класса не обойтись (например, добавление новой секции к отчету), код, конечно, не должен быть статическим, и метод ReportSectionAppender.append(Report report, ReportSection section) без дополнительных условий появляться не должен.
Однако лично у меня есть сильные предубеждения против статических вызовов, из-за которых лично я этой логике не следую. Статические вызовы облегчают написание кода, но у них есть два минуса, которые (лично для меня) перевешивают плюсы. Во-первых, статические вызовы скрывают зависимости и вносят небольшую долю глобального контекста в код - в конструктор класса может передаваться три объекта, а внутри использоваться еще с десяток статических классов, что обнаружится только в тот момент, когда на рефакторинг будет дан зеленый свет, "потому что этот класс почти не затрагивает другие". И, во-вторых, это довольно жесткий хардкод - статический вызов сам по себе нельзя ни подменить другой реализацией, ни обернуть в прокси, не изменив сам код. В случае того же самого рефакторинга это может встать серьезным боком, если архитектура не была продумана идеально изначально (это как раз мой случай).
Что по поводу "лишь бы не создавать экземпляр класса" - это обычные опасения, от которых стоит избавляться. Когда вы пишете программу, ваша первая задача - реализовать поставленные к ней требования, оптимизацией - если она вообще потребуется - можно будет заняться позже. Делайте так, как удобно.
Резюмируя: писать бесконтекстные методы статикой и выносить их в utility-классы - это обычная практика, принятая коммьюнити. Тем не менее, у этого подхода есть минусы, которые заставляют некоторых ее не использовать или использовать по минимуму.
Я всегда когда это возможно, делаю статичные методы для выполнения какой либо задачи. Т.е. статичных методов довольно много.
Я не гуру и не профи Java. Я ее изучаю. Мне как то на курсах сказали, что статик методы и абстрактные классы необходимо использовать с умом.
Т.е. моя мотивация при создании статик методов, "лишь бы не создавать экземпляр класса" - верный ли это подход, если нет был бы рад получить ответ почему нет. Спасибо!
Ответ
Статические и нестатические методы отличаются (главным образом) только наличием одной вещи - контекстом. Если код суммирует два аргумента (пресловутый Math) или преобразовывает массив в список (Arrays.asList()), то ему не нужен для этого внешний контекст (состояние), и такой код, по логике, должен быть статическим. В случаях, когда вызов метода меняет состояние, и без экземпляра класса не обойтись (например, добавление новой секции к отчету), код, конечно, не должен быть статическим, и метод ReportSectionAppender.append(Report report, ReportSection section) без дополнительных условий появляться не должен.
Однако лично у меня есть сильные предубеждения против статических вызовов, из-за которых лично я этой логике не следую. Статические вызовы облегчают написание кода, но у них есть два минуса, которые (лично для меня) перевешивают плюсы. Во-первых, статические вызовы скрывают зависимости и вносят небольшую долю глобального контекста в код - в конструктор класса может передаваться три объекта, а внутри использоваться еще с десяток статических классов, что обнаружится только в тот момент, когда на рефакторинг будет дан зеленый свет, "потому что этот класс почти не затрагивает другие". И, во-вторых, это довольно жесткий хардкод - статический вызов сам по себе нельзя ни подменить другой реализацией, ни обернуть в прокси, не изменив сам код. В случае того же самого рефакторинга это может встать серьезным боком, если архитектура не была продумана идеально изначально (это как раз мой случай).
Что по поводу "лишь бы не создавать экземпляр класса" - это обычные опасения, от которых стоит избавляться. Когда вы пишете программу, ваша первая задача - реализовать поставленные к ней требования, оптимизацией - если она вообще потребуется - можно будет заняться позже. Делайте так, как удобно.
Резюмируя: писать бесконтекстные методы статикой и выносить их в utility-классы - это обычная практика, принятая коммьюнити. Тем не менее, у этого подхода есть минусы, которые заставляют некоторых ее не использовать или использовать по минимуму.
