Йуный джавистЪПрочитайте пожалуйста мой пост внимательно. Он не о трансфере средств. Это предложение язковой фичи.
я понял, к чему был пост. проблема в том, что он является хорошим примером того, как можно было сделать по-другому, чтобы вопроса о тестировании статического метода просто не возникло.
Йуный джавистЪи статический же способ оповещения, так же не дающий никакой возможности в другом месте посылать например вместо мыла смс
Все равно придется передавать параметр, как именно слать оповещение, по мылу или по смс. Не вижу разницы между статик и виртуальным методом.
а она есть. потому что идея не в переопределении метода transfer, а в поручении рассылки отдельному сервису (SRP). будь у нас AccountHelper не статический, и имей он интерфейс NotificationService в качестве зависимости, мы бы поимели кучу профитов, как то:
1) легко делается заглушка для тестирования
2) легко подменяется реализация на рассылку по смс, рассылку на jabber, рассылку на что угодно еще или на все вместе. причем не надо передавать никаких "параметров".
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
<!-- код (почти)условный -->
<!-- определяем базовый тип с некими общими настройками -->
<bean id="abstractNotificationService"/>
<bean id="email" parent="abstractNotificationService">
<property name="templateEngine" value="htmlEngine/>
</bean>
<bean id="sms" parent="abstractNotificationService">
<property name="templateEngine" value="plainTextEngine/>
</bean>
<!-- или даже так -->
<bean id="mass" parent="abstractNotificationService">
<property name="notificationServices">
<list>
<value ref="email"/>
<value ref="sms"/>
</list>
</property>
</bean>
далее суем нужные реализации туда куда надо. ЕСЛИ ДАЖЕ у нас например тяжелый случай, когда в одном и том же месте нужно одному клиенту послать смс, а другому мыло (а третий ваще не хочет, чтоб его спамили), то как один из вариантов - сохраняем в настройках для клиента (бд, xml, whatever) имя бина и инстанциируем его по имени (да, здесь является недостатком хранение бина в виде текста, НО это место легко контролируется тестами, т.е. если мы опечатались в имени, на этапе теста мы отловим исключение). После этого оповещение при трансфере РЕАЛЬНО легко меняется извне без модификации кода - просто говорим, что у клиента 234646 при трансфере использовать оповещение jabber. И да, нам для этого нужна другая зависимость, что-то типа NotificationServiceProvider , которая опять же таки в зависимости от реализации может доставать настройки клиента из базы, файла или еще откуда и отдавать нашему AccountHelper ту реализацию нотификаций, что требуется.
3) в сервисе рассылки в свою очередь можно легко обеспечить всевозможную кучу (в том числе локализованных) темплейтов сообщений, тоже например по принципу у каждого клиента свой темплейт.
Да, все тоже самое, можно тем или иным способом реализовать в коде, с большей или меньшей степенью гибкости. именно по-этому - это лишь вопрос предпочтения, где конфигурировать. Ну и естественно, подобное мы наворачиваем только если нам подобная гибкость нужна. Но как минимум - это независимость от реализации как перевода денег, так и оповещений.
