Blazkowicz KartasДень добрый. Подскажите ламеру ответ на вот какой вопрос.

Есть веб-апп. В нем есть класс с пачкой статик методов. Дергаются его методы достаточно часто и в принципе класс этот достаточно узкое место.
Так вот вопрос - не получу ли я выгрыша в скорости сделав этот класс синглтоном?
Чисто теоретически статический вызов должен быть быстрее, так как он не виртуальный. Но на практике это никакой выигрышь по сравнению с неудобством использования статических методов.

+1

mikkriА если подумать чуть больше выяснится, что синглтоны и статические методы очень тяжело тестировать, так как если класс А зависит от синглотна Б, очень тяжело классу А подсунуть mock object вместо класса Б. Аналогично со статическими методами.

Т.е. мой ответ вам - по возможности разрабатывать дизайн без синглтонов и стараться избегать статических методов, если они делают что-либо сложнее, чем конвертация строки в число или trim.

Если же вас юнит-тестирование и поддержка кода не волнуют, то выбирайте статические методы для реализации простой логики, особенно когда для выполнения метода не важно состояние класса. Если же для выполнения метода важно иметь какой-то заранее подготовленный контекст, синглтоны уместнее.

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

Не надо ляля Дипенденси инжекшн конечно хорошо но палку перегибать не надо - Singleton - он на то и Singleton чтобы можно было тестировать его каак есть без мок объектов

Blazkowicz Java ProgrammerНе надо ляля Дипенденси инжекшн конечно хорошо но палку перегибать не
надо - Singleton - он на то и Singleton чтобы можно было тестировать его каак есть без мок объектов
Перечитай ещё раз что написано, если с первого раза не вникаешь. Класс который использует синглтон трудно тестировать независимо от этого синглтона. Только в купе с ним.

Я вник с первого раза - все прекрасно тестируется писать надо правильно а не пихать синглетоны направо и налево - но "правильный" синглетон - тестированию не помешает

mikkriСказано же, что есть "веб-апп".

В любом случае, как вы предлагаете тестировать класс Б, зависящий от синглтона А?

Junit тестами ))) не собираюсь а тестирую -

Правильный Синглетон - это синглетон который по логике должен являться таковым - один во всем приложении и все! покапайтес в jdk найдете

mikkriСинглтон - это антипаттерн!

Бред не несите - поначитались ерунды где индусы рассказывают про паттерны и туда же
не нравится не юзайте - а бред не несите

Blazkowicz Java ProgrammerЯ вник с первого раза
Тем неменее твой пост был про тестирование синглтона, а не зависимостей.

постом выше

Blazkowicz Java ProgrammerПравильный Синглетон - это синглетон который по логике должен являться таковым - один во всем приложении и все! покапайтес в jdk найдете
Одно вприложение натянутое на несколько кластре это все ещё одно приложение. Так что критерий не совсем верный.

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

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

Берем практичекий пример - есть какая-нибудь фабрика объектов ObjectFactory, реализованная как синглтон. Класс из уровня бизнес-логики ClassA использует эту фабрику для того, чтобы получить данные для обработки.

Теперь стоит задача протестировать бизнес-методы ClassA, учитывая, что ObjectFactory подключается к JMS в формате XML, потом парсит его и превращает в Java объект, потом лезет в БД и оттуда вытаскивает дополнительные данные, такие, как имя клиента и его кредитный лимит, далее этот Java объект возвращется ClassA для обработки.

В реальной системе за счет кеширования ObjectFactory будет иметь неплохую производительность. Но вот при юнит-тестировании нам нужно для каждого теста НОВЫЙ инстанс ObjectFactory, чтобы тесты не оказывали влияния друг на друга.

Кстати, а как вы каждому тесту выдадите по своему, новому, инстансу синглтона?

Внимательно слушаю вас.

Прекрасно все тестируется поверьте!
Зачем каждому тесту выдавать свой инстанс? зачем вам плодить неплодимое???

Java Programmer mikkri Софтверный проктологВо время тестирования чихать на то, насколько ресурсоемки операции в синглтоне (к тому же я не очень себе представляю, что это за зверь такой получится).
Т.е. для вас не важно, сколько по времени занимает прогон всех юнит-тестов?

Берем практичекий пример - есть какая-нибудь фабрика объектов ObjectFactory, реализованная как синглтон. Класс из уровня бизнес-логики ClassA использует эту фабрику для того, чтобы получить данные для обработки.

Теперь стоит задача протестировать бизнес-методы ClassA, учитывая, что ObjectFactory подключается к JMS в формате XML, потом парсит его и превращает в Java объект, потом лезет в БД и оттуда вытаскивает дополнительные данные, такие, как имя клиента и его кредитный лимит, далее этот Java объект возвращется ClassA для обработки.

В реальной системе за счет кеширования ObjectFactory будет иметь неплохую производительность. Но вот при юнит-тестировании нам нужно для каждого теста НОВЫЙ инстанс ObjectFactory, чтобы тесты не оказывали влияния друг на друга.

Кстати, а как вы каждому тесту выдадите по своему, новому, инстансу синглтона?

Внимательно слушаю вас.

Прекрасно все тестируется поверьте!
Зачем каждому тесту выдавать свой инстанс? зачем вам плодить неплодимое???

Надо его изменять и вабще кто сказал что вам тут нужен синглетон ??

mikkri Java ProgrammerНадо его изменять и вабще кто сказал что вам тут нужен синглетон ??
Могу я это считать вашим согласием с тем, что синглтоны мешают юнит-тестированию?


Неет :) вы можете считать этот пост моис убеждением что каждый тест надо подготавливать - собирать для него заглушки - что равносильно сбросу состояния синглетона и инициализации его заново )

mikkri Софтверный проктологЗачем?
Мы же оттестировали класс синглтона и считаем, что он замечательно работает.
От того, что ObjectFactory работает правильно и Тест2 проходит после запуска Тест1 не значит, что Тест2 пройдет, если его запустить автономно.

А знаете что есть такая штука - что некоторые вещи просто принципиально нельзя тестировать безотносительно контекста

mikkri Софтверный проктолог mikkri
Даже если допустить, что мы можем использовать тот же инстанс ObjectFactory, что делать с производительностью?
Ну если мы используем тот же инстанс, то производительность в итоге будет ровно такой же, как и в реальной работе.
Не верно в общем случае, потом, для юнит-тестов предпочтительно иметь очень высокую производительность, чтобы их можно было гонять десятки раз за день без заметных трат времени.

Не понял а что создание объекта и его инициализация - займет больше времени чем переинициализация синглетона?
В общем так - нужен синглетон - юзай не нужен - не юзай - я не прав ??

mikkri Софтверный проктолог mikkri
Не верно в общем случае, потом, для юнит-тестов предпочтительно иметь очень высокую производительность, чтобы их можно было гонять десятки раз за день без заметных трат времени.
Да что же у вас там за логика такая, что тратит такое гигантское количество времени?
Если каждый раз при запуске теста нужно установить подключение к JMS Queue, опубликовать туда тестовое сообщение, потом подключиться в БД и выполнить несколько запросов, тесты будут долго работать. Если же вместо реальной реализации ObjectFactory подсунуть mock object, то процесс прогона теста будет занимать очень мало времени, вряд ли больше 1-2 секунд даже в самом сложном сценарии.

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

А где вы видели приложение без неявных связей! ??

mikkri Java ProgrammerА где вы видели приложение без неявных связей! ??
В книжке, называется Hello World!

А если серьезно, то, что в любом большом приложении есть неявные связи не значит, что их размножение нужно поощрять. Наоборот по мере возможностей нужно их рефакторить и заменять на явные.

)) кто спорит - я же сказал что Синглетон не надо пихать во все дыры - но то что это антипаттерн я с Вами не согласен

mikkri ДуремарПри этом логика подгрузки не зашита в синглтоне - каждый в каждый синглтон устанавливается (при инициализации приложения) некий Loader, который и грузит данные. При реальной работе устанавливеется Loader который стучится к серверу приложений, при тестировании "фальшивый" Loader - который возвращает предопределенный справочник.
Здоровая критика принимается!
Вот тут и проблема с инициализацией синглтона. Что делать, если кто-то к нему обратиться до инициализации? Что делать, если кто-то попробует сделать повторную инициализацию?

Мне лично сейчас кажется, что подход, пропогандируемый Spring Framework - когда все зависимости явно задаются через поля классов, гибче и удешевляет поддержку приложения. В такой ситуации у вас просто не будет доступа к вашему кешу объектов до его инициализации.

Даа - мне тоже нравиться спринг - я тоже его активно юзаю - но есть просто ситуации когда нельзя использовать спринг ну бывает такое