Использование getBean в противоположность инжекции метода в Spring
В JavaScript void не является ключевым словом, не является объявлением типа, не является именем переменной и не является ни функцией, ни объектом. void - это префиксный оператор, аналогичный -, --, ++ и !. Вы можете добавить его к любому выражению, и это выражение будет иметь неопределенное значение.
Он часто используется в букмарклетах и встроенных обработчиках событий, как в этом довольно частом примере:
<a href="javascript:void(0)">do nothing</a>
То, как он используется в этом примере, делает его похожим на вызов функции, когда на самом деле это просто слишком умный способ получить примитивное значение undefined. Большинство людей не совсем понимают истинную природу void в JavaScript, и это может привести к множеству неприятных ошибок и странных неожиданных событий.
К сожалению, я думаю, что оператор void является единственным действительно гарантированным способом получить значение undefined в JavaScript, поскольку undefined, как указано в другом ответе, является именем переменной, которое можно переназначить, и {}.a может быть испорченным Object.prototype.a = 'foo'
Обновление: Я подумал о другом способе генерации undefined:
(function(){}())
Да, немного многословно, и это еще менее ясно, что возвращение «неопределенного» является его целью.
3 ответа
Внедрение сеттера, внедрение свойств или внедрение конструктора - все это создает слабосвязанное приложение, которое намного проще протестировать с помощью имитации. Это также предотвращает прямую зависимость любого из ваших классов от классов Spring (или других контейнеров IoC). В конечном итоге это просто более чистое общее решение, когда вам не нужно вручную вызывать getBean ().
Я думаю, вы должны привыкнуть к понятию настройки зависимостей. «Магия» на самом деле вовсе не магия, это просто то, с чем вы будете чувствовать себя комфортно, когда будете ее использовать.
Рассматривали ли вы фабричный подход?
public interface ComponentFactory<T> {
T create();
}
public class ScreenFactory implements ComponentFactory<Screen> {
@Override
Screen create() { ... }
}
public class MyApp {
private ComponentFactory<Screen> screen1;
public void actionPerformed(Event e) {
setScreen(screen1.create());
}
public void setScreen1(ComponentFactory<Screen> screen1) {
this.screen1 = screen1;
}
private void setScreen(Screen screen) { ... }
}
в сочетании с:
<bean id="screenFactory" class="com.myclass.ScreenFactory"/>
<bean id="myapp" class="...">
<property name="screen1" ref="screenFactory"/>
</bean>
Вы, конечно, можете автоматически подключить вышеуказанное.
Проблема с тем, что вы делаете, заключается в том, что он жестко кодирует bean-компонент, который вы создаете, и связывает вашу реализацию с ApplicationContext . Если вам когда-нибудь понадобится имитировать и / или модульное тестирование ваших приложений / компонентов, то это ' сделаю вашу жизнь невероятно сложной. Приведенное выше заводское решение сделает его тривиальным.
Если вы просто хотите избавиться от getBean, рассмотрите возможность использования ServiceLocatorFactoryBean . Но насколько хорошо это работает для вас, может зависеть от того, откуда в вашем приложении берется строка "screen1".