Йуный джавистЪЯ бы лучше ввел в яву такую конструкцию. Например, есть static функция



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

Ищущий ЗнанияАбсолютно везде в инете говорят, что надо использовать спринг как клей для модулей проекта. Но я сколько примеров не видел, они все притянуты за уши и не объясняют а в чем собственно цимес
В чем цимес конкретно спринга или ioc в целом? Если ioc, то хороший пример как не надо привел вумник парой постов выше - в этом примере прекрасно все: и статический метод трансфера средств, делающий невозможным существование более одной реализации, и статический же способ оповещения, так же не дающий никакой возможности в другом месте посылать например вместо мыла смс. К тому же пациент тщетно бьется с проблемой затрудненного тестирования подобного говнокода, при этом авторитетно заявляя, что в ява все равно никто ничего не тестит, проверки на этапе компиляции должно хватить всем, а моки и прочую херню слишком сложно осилить.



Если говорить конкретно о спринге - то тут скорее дела вкуса, почти. Отвлекаясь от того, что в спринге существует огромная инфраструктура по интеграции большинства мыслимых mainstream фреймворков и прочие плюшки, все сводится к тому, нравится ли тебе конфигурация в xml или ты предпочитаешь конфигурацию в коде (тот же спринг, guice, tapestry-ioc). Только под конфигурацией в коде подразумевается нечто вида bind(Service.class).to(MyServiceImpl.class) не new MyServiceImpl() в 10 местах.

Йуный джавистЪПример, разумеется, упрощенный.
разумеется

Йуный джавистЪПрочитайте пожалуйста мой пост внимательно. Он не о трансфере средств. Это предложение язковой фичи.
я понял, к чему был пост. проблема в том, что он является хорошим примером того, как можно было сделать по-другому, чтобы вопроса о тестировании статического метода просто не возникло.


Йуный джавистЪи статический же способ оповещения, так же не дающий никакой возможности в другом месте посылать например вместо мыла смс
Все равно придется передавать параметр, как именно слать оповещение, по мылу или по смс. Не вижу разницы между статик и виртуальным методом.
а она есть. потому что идея не в переопределении метода transfer, а в поручении рассылки отдельному сервису (SRP). будь у нас AccountHelper не статический, и имей он интерфейс NotificationService в качестве зависимости, мы бы поимели кучу профитов, как то:
1) легко делается заглушка для тестирования
2) легко подменяется реализация на рассылку по смс, рассылку на jabber, рассылку на что угодно еще или на все вместе. причем не надо передавать никаких "параметров".



далее суем нужные реализации туда куда надо. ЕСЛИ ДАЖЕ у нас например тяжелый случай, когда в одном и том же месте нужно одному клиенту послать смс, а другому мыло (а третий ваще не хочет, чтоб его спамили), то как один из вариантов - сохраняем в настройках для клиента (бд, xml, whatever) имя бина и инстанциируем его по имени (да, здесь является недостатком хранение бина в виде текста, НО это место легко контролируется тестами, т.е. если мы опечатались в имени, на этапе теста мы отловим исключение). После этого оповещение при трансфере РЕАЛЬНО легко меняется извне без модификации кода - просто говорим, что у клиента 234646 при трансфере использовать оповещение jabber. И да, нам для этого нужна другая зависимость, что-то типа NotificationServiceProvider , которая опять же таки в зависимости от реализации может доставать настройки клиента из базы, файла или еще откуда и отдавать нашему AccountHelper ту реализацию нотификаций, что требуется.

3) в сервисе рассылки в свою очередь можно легко обеспечить всевозможную кучу (в том числе локализованных) темплейтов сообщений, тоже например по принципу у каждого клиента свой темплейт.

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

Йуный джавистЪЯ там писал о тестах, в которых класс тестится в полной изоляции. По моим наблюдениям, в яве такое тестирование применяется редко, чаще тестирование делается на уровне полноценных сценариев.
т.е. unittest :) . мягко говоря странное наблюдение. ну и собственно говоря, само обобщение довольно смелое. я например довольно часто пишу тесты именно для конкретных классов, потому что тестирование целого тандема часто гораздо более затруднительно, особенно когда веб вовлечен - гораздо проще потестировать дао, чем поднимать джетти и генерить клики в селениуме, хотя естественно одно не заменяет другого полностью.

собственно коль скоро речь пошла про тестирование, то здесь конфигурация в xml очень сильно помогает, потому что можно по тому же принципу, что и организация пакетов в ява, подключить различные комбинации "подмодулей", подсунув например пачке дао ссылку на коннект к тестовой базе. да, с помощью кода можно достигнуть схожего эффекта, если взять за основу понятие модуля, существующee в guice и в tapestry-ioc, ну соответственно разбивать конфигурацию на логические модули и подключать те, что надо.


Йуный джавистЪа моки и прочую херню слишком сложно осилить

Так на самом деле сложно. Есть JMock, есть EasyMock, у всех разное API, не особо интуитивное.
да блин, ну фигли сложного? лично я в свое время взял первое попавшееся (EasyMock) и в 20 минут разобрался с минимумом, необходимым, чтобы тесты работали. главное что выбор есть, а разбираться приходится с чем-то так или иначе. когда нету желания разобраться, все кончается тем, что тестов в итоге просто нет.

Йуный джавистЪТак значит все же с модификацией - новый класс NotificationServiceProvider понадобился

вообще-то он понадобился еще в тот момент, когда у нас возникла сама постановка задачи - оповещение настраиваемо под клиента. кроме того, когда подобная гибкость не нужна, а нужно разные реализации в разных местах (ну например мобильные клиенты получают смс, веб-клиенты мыло) - нам бы просто хватило двух реализаций NotificationService, клиентский код бы выглядел едино (зависимость от accounthelper), а сам accounthelper имел мы две "конфигурации". А как тоже самое со статическим методом разрулить, если он у тебя повсюду в коде натыкан? А никак. Search&Replace + Find Usages в руки. Оно понятно, что упорство и труд все переколбасят.

Йуный джавистЪ. Также хочу отметить, что конфиг спринга - тоже код.
в некотором смысле. я предпочитаю "конфигурация". если ты о том, что его придется время от времени модифицировать, то да - придется. но не в том дело. вопрос в том, во скольких местах код/конфигурацию придется модифицировать при каждом изменении задачи.

Йуный джавистЪНе понимаю, почему я не могу из статик метода залезть в базу, посмотреть как клиент хочет получить оповещение и в зависимости от этого отправить его по смс или емейлом.
Хехе...если у тебя в статик методах при вызове происходит поностью "динамическая реконфигурация" (а не то, как это было в примере) - то ты просто сделал аналог предложенной мной системы в коде. Т.е. если у тебя статик метод допускает любое количество внутренних реализаций одновременно. Тогда дело упирается просто в то, кому что удобней. Ну отвлекаясь от очевидных проблем с тестированием (и thread safety до кучи). Разве нет?

Йуный джавистЪт.е. unittest :) . мягко говоря странное наблюдение.

В 90% случаев вообще нет никаких тестов. Это понятно - если проект активно развивается, то нет времени писать тесты, все фигачат чтобы как можно скорее выдать новую версию.
бывает. лично я тоже часто дописываю тесты уже потом, когда есть время, или наступил в каком-то месте на грабли. Если честно, я уже перестал даже считать, сколько раз они меня выручали. а есть пару мест, в которых без тестов вообще нереально проверить правильность работы. оно понятно, что обстоятельства часто сильнее нас. просто некоторые как-то пытаются с этим бороться, а другие прячутся за "у нас не было времени". а чаще всего просто лень.

Ищущий ЗнанияХоть какая-то приближенность к реальности
что значит хоть какая-то? основано на реальных событиях ;)

Йуный джавистЪавторкроме того, когда подобная гибкость не нужна, а нужно разные реализации в разных местах (ну например мобильные клиенты получают смс, веб-клиенты мыло)
А откуда берется признак того, мобильный это клиент или веб? Если признак приходит как аргумент в AccountHelper, то AccountHelper может просто передать этот аргумент в статик функцию оповещения.
та не, забудь ты про признаки, флаги и параметры. accounthelper это сервис, который делегирует две "ответственности" двум другим сервисам, и оперирует он только теми данными, что нужны непосредственно для выполнения операций. Дальше мы в коде мобильного клиента или вебе или еще где инжектируем (уж как хотите, через код или спринг) разные конфигурации того же самого accounthelper, только в одной рассылкой занимается смс, а другой мыло.
пример для понимания



конфигурация




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

Йуный джавистЪТаким образом проведен рефакторинг
и мы написали свой google guice, с чем всех и поздравляю (правда куча вопросов осталась за бортом, например scope создаваемых объектов, и как эту конфигурацию частично переиспользовать в тестах, заменив во всех созданных дао один коннект другим. но в конце концов пофиг - первый блин комом).

пора определиться, либо мы в принципе против ioc, либо нам конкретно спринг не нравится. Вот Петру например конкретно спринг не нравится, он на него как красная тряпка действует, даже сильней чем hibernate. в остальном это чисто дело вкуса - вот я когда-то с леонидом спорил, ему описание интерфейса в ява коде нравится, а я предпочитаю xml/html

Йуный джавистЪСмотри, account helper скорее всего нужен как часть какого нибудь TransactionHelper. TransactionHelper тоже будет существовать в трех ипостасях: transactionHelperForWeb, transactionHelperForCron, accountHelperForMobile?
ты сейчас искусственно пытаешься усложнить задачу выдуманного примера, не озвучив финальных требований к архитектуре. без этого сложно сказать что-то определенно. Так чисто абстрактно - да, нам понадобится столько TransactionHelper, сколько нужно отличных поведений. А может при разумной постановке задачи AccountHelper является ненужной сущностью.