Я объединяю ветвь CVS, и одним из больших изменений является замена, где бы она ни происходила из шаблона Singleton с абстрактными классами, которые имеют статический блок инициализации и все статические методы.
Это что-то, что стоит сохранить, поскольку для этого потребуется слить много конфликтов, какую ситуацию я буду искать, чтобы этот рефакторинг был полезен?
Мы запускаем это приложение под Weblogic 8.1 (так JDK 1.4.2)
Извините, Томас, позвольте мне уточнить..
версия HEAD имеет традиционный шаблон singleton (частный конструктор, getInstance() и т.д.)
версия ветки не имеет конструктора, является "общедоступным абстрактным классом" и модифицировала все методы для объекта "статические". Код, который использовался в частном конструкторе, перемещается в статический блок.
Затем изменяются все применения класса, вызывающие множественные конфликты в слиянии.
Есть несколько случаев, когда это изменение было сделано.
С точки зрения производительности в режиме исполнения, разница действительно незначительна. Основное различие между ними заключается в том, что "статический" жизненный цикл связан с загрузчиком классов, тогда как для singleton это обычный жизненный цикл экземпляра. Обычно лучше избегать бизнеса ClassLoader, вы избегаете некоторых сложных проблем, особенно когда вы пытаетесь перезагрузить веб-приложение.
Я бы использовал одноэлемент, если ему нужно было сохранить какое-либо состояние и статические классы в противном случае. Нет смысла создавать что-то, даже один экземпляр, если ему не нужно что-то хранить.
Статичность является плохим для расширяемости, поскольку статические методы и поля не могут быть расширены или переопределены подклассами.
Это также плохо для модульных тестов. В пределах unit test вы не можете переносить побочные эффекты от разных тестов, поскольку вы не можете управлять загрузчиком классов. Статические поля, инициализированные в одном unit test, будут видны в другом или, что еще хуже, текущие тесты одновременно дают непредсказуемые результаты.
Синглтон, как правило, хорошо работает при использовании экономно. Я предпочитаю использовать структуру DI и позволяю мне управлять своими экземплярами для меня (возможно, в разных областях, как в Guice).
Если мой исходный пост был правильным пониманием, и обсуждение с Солнцем, которое было связано с ним, является точным (что, я думаю, это может быть), тогда я думаю, что вам нужно сделать компромисс между ясностью и производительностью.
Задайте себе следующие вопросы:
По моему опыту, единственное, что имеет значение, - это то, что легче обманывать в модульных тестах. Я всегда чувствовал, что Синглтон легче и естественнее издеваться. Если ваша организация позволяет использовать JMockit, это не имеет значения, так как вы можете преодолеть эти проблемы.
Помогает ли эта дискуссия? (Я не знаю, запретил ли он табу связываться с другим форумом программирования, но я бы предпочел не просто процитировать все обсуждение =))
Обсуждение Sun по этому вопросу
Приговор, по-видимому, заключается в том, что в большинстве случаев он не делает достаточной разницы с материей, хотя технически статические методы более эффективны.
Напишите код для измерения производительности. Ответ будет зависеть от JVM (Sun JDK может работать иначе, чем JRockit), а флаги VM используют ваше приложение.