В течение долгого времени SpringFramework, как старшего брата Java-разработки корпоративного уровня, часто спрашивают в интервью. Хотя некоторые базовые вопросы могут не особенно цениться интервьюерами и соискателями, если их действительно задают, могут ли они ответить точно, всесторонне и подробно, все же легко отразить уровень.
В следующей серии я постепенно подведу итоги некоторых распространенных, но трудных для ответа вопросов в Spring и поделюсь ими со своими друзьями.
Тема этой статьи: Как максимально полно, точно и подробно ответить на IOC Spring.
В: Что такое МОК?
Это вопрос, который кажется очень простым и кажется очень безмозглым.Многие соискатели ответят на этот вопрос, не задумываясь, и быстро ответят на очень простой, но в то же время бессодержательный вопрос.
небрежный ответ
- IOC - это инверсия управления, инверсия управления.
Позвольте спросить, дорогая, вы занимаетесь переводом существительных?
Даже если вы действительно занимаетесь переводом существительных, вы не должны просто объяснять полное название аббревиатуры, и все должно быть готово.Интервьюеры не должны просто хотеть услышать немногоБар.
направление выключено
- IOC — это инверсия управления, которая дает Spring поддержку зависимостей между объектами, а сама программа больше не поддерживается.
Это в целом объясняет основную идею IOC:Передано право поддерживать зависимости между объектами, но обратите внимание, что мы просим МОК,Этот вопрос только к самому МОК, не относящийся к конкретной технологии.МОК больше, чем весна, но самым мощным и широко используемым является Spring.
Итак, ребятаОтвечая на вопросы о теориях, концепциях и т. д., не упоминайте прямо конкретные технологии в объяснении концепции.Технологии являются реализацией концепций и теорий, и существует более. Просто вытащите один, интервьюер может подумать: Вы только это знаете?
справочный ответ
Этот ответ предназначен только для справки и может быть динамически скорректирован в соответствии с вашим собственным запасом знаний.
Полное название МОКИнверсия контроляИнверсия управления, этопринципы программирования, который спроектирован и спроектирован для достиженияРазвязка между компонентами, основная идеяпередача управления.
Здесь упоминаются несколько моментов:
- Принципы программирования: этотеория, а не конкретная технология посадки
- Развязка между компонентами: так называемаясвязь, о котором сказано вышезависимости между объектами;разъединение,то естьУдалить зависимости между объектами.
- Когда дело доходит до разделения, интервьюер может продолжать спрашивать «что такое разделение» или может не спрашивать «зачем использовать Spring».
- Передача прав управления: чтобы добиться разделения, IOC передаетАктивные зависимости заменены на пассивные получающие зависимости(переход от прямого нового к набору)
В: Разница между IOC и DI
Если вы мало что знаете о реализации IOC, или просто слишком привыкли использовать SpringFramework, или жестко изучаете SpringFramework, ответ обычно такой:
- МОК - это DI.
Если вы ответили на этот вопрос, а интервьюером оказался тот же человек, что и вы, то поздравляю вас с "слепой кошкой и мертвой мышью"! Потому что ответ действительноБольшая ошибкаАх, в IOC есть нечто большее, чем DI!
Правильный ответ должен быть:
- IOC — это идея и принцип программирования, а DI — реализация идеи IOC.
- Реализация IOC включает поиск зависимостей и внедрение зависимостей.
Как упоминалось выше, IOC — это просто идея, и его цель — преобразовать управление зависимостями между объектами. Любой, кто использовал SpringFramework, знает, что вы нигде не видели кода, который напрямую пишет IOC, а IOC отражается некоторыми методами реализации.
Если вы ответите, как указано выше, это может привести к следующему вопросу:
Что такое поиск зависимостей и внедрение зависимостей? Как их отличить?
В ответ на эту проблему лучше не выдвигать объяснение кода, как только оно появится, лучше сначала теорию, а затем код.
В общем, сравнение поиска зависимостей и внедрения зависимостей обычно можно сравнить по следующим параметрам:
| Поиск зависимостей | внедрение зависимости | |
|---|---|---|
| Метод реализации | Активное получение с использованием контекста (контейнера) | Контекстно-зависимый пассивный прием |
| Цель действия | Обычно это локальная переменная в теле метода, но она также может быть членом объекта. | Обычно член объекта |
| API-зависимости | Зависит от API инфраструктуры IOC (должен манипулировать API контейнера) | Может быть независимым (просто укажите метод установки) |
| applicationContext.getBean(beanName) | public void setXXX() { ... } |
В: Какие IOC реализованы в Spring Framework?
На самом деле не будет друзей, которые могут только ответитьApplicationContextНу, когда я начал учиться, я должен был знать, что есть еще одинBeanFactoryБар. Это абстракция двух основных контейнеров IOC в Spring Framework.BeanFactoryОн просто предоставляет базовые возможности управления контейнерами,ApplicationContextНа этой основе сделано более полное и мощное расширение. Конкретное сравнение может относиться к следующей таблице:
| Feature | BeanFactory |
ApplicationContext |
|---|---|---|
| Создание экземпляра/проводка компонента — создание экземпляра компонента и внедрение свойств | Yes | Yes |
| Комплексное управление жизненным циклом — управление жизненным циклом | No | Yes |
Automatic BeanPostProcessorрегистрация - поддержка постпроцессора Bean |
No | Yes |
Automatic BeanFactoryPostProcessorрегистрация - поддержка постпроцессора BeanFactory |
No | Yes |
Convenient MessageSourceдоступ (для интернализации) - служба преобразования сообщений (для интернационализации) |
No | Yes |
Built-in ApplicationEventмеханизм публикации — механизм публикации событий (управляемый событиями) |
No | Yes |
Относительно полный пример ответа приведен ниже. Друзья могут изменить некоторые детали описания в соответствии со своими знаниями и пониманием:
BeanFactoryинтерфейс обеспечиваетАбстрактная конфигурация и механизм управления объектами,ApplicationContextдаBeanFactoryсубинтерфейс, этоУпрощенная интеграция с АОП, механизм сообщений, механизм событий,так же какРасширения для веб-среды(WebApplicationContextЖдать),BeanFactoryНет таких расширений.
ApplicationContextВ основном он расширяет следующие функции: (Часть в скобках предназначена для объяснения некоторых простых описаний расширенных функций или базовой реализации принципа, и лучше ответить на них)
-
поддержка АОП(
AnnotationAwareAspectJAutoProxyCreatorПосле инициализации Бина) -
Настроить метаинформацию(
BeanDefinition,Environment, аннотации и др.) -
Управление ресурсами(
ResourceАннотация) -
механизм управления событиями(
ApplicationEvent,ApplicationListener) -
Обмен сообщениями и интернационализация(
LocaleResolver) -
EnvironmentАннотация(После SpringFramework 3.1)
Вопрос: Как внедряется внедрение зависимостей? Какая разница?
Обратите внимание, что эта проблема не имеет никакого отношения к SpringFramework, сам метод внедрения должен быть реализацией внедрения зависимостей, а код фреймворка — реализацией этого метода.
Его можно сравнить по следующим параметрам:
| Инъекционный метод | Является ли введенный член изменчивым | Следует ли полагаться на API инфраструктуры IOC | сцены, которые будут использоваться |
|---|---|---|---|
| Внедрение конструктора | неизменный | Нет (xml, программная инъекция не зависит) | Неизменная фиксированная инъекция |
| ввод параметров | неизменный | Да (интрузивная инъекция может быть выполнена только с аннотациями-аннотациями) | Обычно используется для неизменяемой фиксированной инъекции |
| инъекция сеттера | Переменная | Нет (xml, программная инъекция не зависит) | Внедрение необязательных свойств |
В основном, задавая этот вопрос, можно задать другой вопрос:
Как вы думаете, какой способ лучше? Почему?
Как только «опрометчивые» кандидаты наконец дошли до открытых вопросов, они быстро заиграли вольно:
Я думаю, что ввод параметров — это хорошо, потому что я привык писать, как удобно аннотировать параметры!
Вы так сказали, что подумал интервьюер: Это все? Вот и все? ? ? И тогда впечатление о вас может ухудшиться.
Такого рода вопросы, помимо выражения субъективного мнения, больше касаютсяПоддержите свою точку зрения на основе некоторых уже существующих аргументов, лучшим обсуждением должна быть официальная документация.
Официальная документация SpringFramework рекомендует разные методы внедрения в разных версиях:
- SpringFramework 4.0.2И прежде рекомендуется инъекция сеттера, причина в том,Когда bean-компонент имеет несколько зависимостей, список параметров конструктора будет очень длинным.; и еслиЕсли не все свойства зависимостей в bean-компоненте требуются, инъекция станет более проблематичной.;
- 4.0.3Внедрение конструктора и более поздние версии официально рекомендуются по той причине, чтоЗависимости, введенные конструктором, являются неизменяемыми, полностью инициализированными и гарантированно не равны нулю.;
- Конечно4.0.3И в официальных документах тоже сказано потом, еслиЭто правда, что список параметров конструктора слишком длинный. Возможно, у bean-компонента слишком много обязанностей. Ответственность компонента должна быть демонтирована..
Q: Какие аннотации для внедрения компонентов? Какая разница?
Я думаю, что большинство моих друзей могут ответить@Autowiredа также@ResourceЧто ж, если вы ответите на эти два, это докажет, что вы должны были использовать его и будете использовать. но ты можешь ответить@Inject, что доказывает, что вы действительно понимаете эти внедренные аннотации. Как кандидат, вы должны отвечать при ответе на вопросыкак можно полнееПо уважительной причине, вот сравнение этих аннотаций:
| аннотация | Инъекционный метод | Поддерживать ли @Primary | источник | Процесс, когда Bean не существует |
|---|---|---|---|---|
| @Autowired | Вводить по типу | да | Собственные аннотации SpringFramework | Вы можете указать required=false, чтобы избежать сбоя инъекции |
| @Resource | Вводить по имени | нет | Спецификация JSR250 | Будет выдано исключение, если указанный bean-компонент не существует в контейнере. |
| @Inject | Вводить по типу | да | Спецификация JSR330 (требуется пакет jar для импорта) | Будет выдано исключение, если указанный bean-компонент не существует в контейнере. |
Аналогично предыдущему, если задан этот вопрос, можно продолжать задавать следующий вопрос:
Как решить проблему инъекции, когда есть несколько компонентов одного типа?
Вероятно, большинство мелких партнеров могут ответить на следующие решения:
-
@Resource: указывает внедренный bean-компонент по имени -
@Qualifier:Сотрудничать@AutowiredИспользуется аннотация.Если аннотированный член/метод находит несколько bean-компонентов одного типа при внедрении в соответствии с типом, он будет искать конкретный bean-компонент в соответствии с именем, объявленным в аннотации. -
@Primary:Сотрудничать@BeanИспользуется аннотация.Если в IOC-контейнере одновременно зарегистрировано несколько bean-компонентов одного типа, используйте@Autowired,@InjectАннотация будет введена при аннотировании@PrimaryАннотированные бобы
На самом деле можно предложить и другое решение: поставитьИмя введенного поля совпадает с именем компонента, это также может решить проблему не быть единственным bean-компонентом во время инъекции.
Приведенные выше вопросы представляют собой некоторые распространенные вопросы о SpringFramework и IOC, но вопросы не являются чем-то незнакомым, но если вы хотите ответить всесторонне и подробно, вам все равно придется много работать. Я надеюсь, что друзья смогут что-то получить, бегло ответить на интервью и выиграть предложение!
Разобраться в проблемах не просто, не поддержите ли вы автора? (плохо)