SpringFramework, as the big brother of Java enterprise development, has always been asked in interviews. Although some basic questions may not be so special by the interviewer and job seekers, but if really asked, can answer accurate, comprehensive, depth, or it is easy to reflect the level.
In the next series, I will slowly summarize some common but difficult questions in Spring and share them with friends.
The topic of this article: How to answer Spring’s IOC as fully, accurately and deeply as possible.
Q: What is IOC?
This is an incredibly simple and seemingly mindless question, and many job seekers respond to it without thinking and with a quick, simple answer that doesn’t have much substance.
Snap answer
- IOC is the Inverse of Control.
May I ask, dear, are you a noun translator?
Even if you are really doing a noun translation, you should not just explain the full name of the abbreviation, or at least explain something, as an interviewer should not only hear so little.
The direction of wide
- IOC is a reversal of control that places the maintenance of dependencies between objects in the hands of Spring, rather than the program itself.
In general, the core idea of IOC is explained: the right to maintain the dependency relationship between objects has been transferred. However, please note that we are asking IOC. This question is only about IOC itself, and has nothing to do with specific technologies. There is more to IOC than Spring; it is simply the most powerful and widely used at the moment.
Therefore, when answering questions about theories and concepts, do not directly mention specific technologies in the concept explanation. Technologies are the implementation of concepts and theories, and there is more than one kind. By naming just one, the interviewer might wonder: Is this the only one you know?
A reference answer
The answer is for reference only and can be adjusted dynamically according to your knowledge reserve.
IOC’s full name is Inverse of Control, which is a programming principle whose design and architecture can achieve the decoupling between components, with the core idea of transferring Control.
There are several points:
- Programming principles: It is a theory, not a technical implementation
- Decoupling between components: so calledcoupling, which is mentioned aboveDependencies between objects;The decoupling, it isRemoves dependencies between objects.
- When it comes to decoupling, it’s possible that the interviewer will continue to ask “what is decoupling?” or it’s possible that the interviewer will stop asking “Why Spring?
- Transfer of control: In order to achieve decoupling, IOC changes the original active dependence between objects into passive receiving dependence (from direct new to SET)
Q: The difference between IOC and DI
If you don’t know much about IOC implementations, or are just too used to using the SpringFramework, or are rigidly learning the SpringFramework, the answer is usually something like this:
- IOC is DI.
If you answer this question and the interviewer happens to be like you, congratulations! Because this answer is really wrong, IOC is not only DI!
The correct answer is:
- IOC is a kind of thought and programming principle, and DI is a way to realize IOC thought.
- IOC is implemented in two ways: Dependency Lookup and Dependency Injection.
As mentioned above, IOC is just an idea that is intended to shift the control of dependencies between objects. Those of you who have used the SpringFramework know that you haven’t seen code written directly to IOC anywhere, but rather implementations of IOC.
If you follow the above answer, it may lead to the following question:
What are dependency lookup and dependency injection respectively? How do you tell them apart?
For this problem, it is best not to come up with the code to explain, it is best to first theory after code.
In general, dependency lookup and dependency injection can be compared in the following dimensions:
| Rely on to find | Dependency injection | |
|---|---|---|
| implementation | Active fetch using context (container) | Passive reception dependent on context |
| target | It is usually a local variable in the body of a method, but it can also be an object member | Usually an object member |
| API rely on | Apis that rely on the IOC framework (apis that must manipulate containers) | Can not rely on (expose setter methods) |
| applicationContext.getBean(beanName) | public void setXXX() { … } |
Q: what IOC is implemented in the SpringFramework?
“ApplicationContext” means “BeanFactory” or “ApplicationContext” means “BeanFactory”. This is an abstraction of the two core IOC containers in the SpringFramework. The BeanFactory simply provides a basic container-managed capability, and ApplicationContext extends it even further. For specific comparison, please refer to the following table:
| Feature | BeanFactory |
ApplicationContext |
|---|---|---|
| Bean Instantiation/Wiring — Instantiation and property injection of a Bean | Yes | Yes |
| Integrated lifecycle management — lifecycle management | No | Yes |
Automatic BeanPostProcessorRegistration — Bean post-processor support |
No | Yes |
Automatic BeanFactoryPostProcessorRegistration — BeanFactory post-processor support |
No | Yes |
Convenient MessageSourceAccess (for Internalization) — Message Transformation Service (internationalization) |
No | Yes |
Built-in ApplicationEventPublication Mechanism – event publishing mechanism (event driven) |
No | Yes |
The following is a complete example of the answer, you can adjust some of the details of the description according to their knowledge and understanding:
The BeanFactory interface provides an abstract configuration and object management mechanism. ApplicationContext is a subinterface of BeanFactory, which simplifies the integration, message mechanism, event mechanism with AOP. And extensions to the Web environment (WebApplicationContext, etc.) that the BeanFactory doesn’t have.
ApplicationContext mainly extends the following functions :(the sections in parentheses explain some simple descriptions of the extended functions or underlying implementations of the principles.
- AOP support(
AnnotationAwareAspectJAutoProxyCreatorAfter the Bean is initialized) - Configuring meta Information(
BeanDefinition、EnvironmentNotes, etc.) - Resource management(
ResourceAbstract) - Event-driven mechanism(
ApplicationEvent、ApplicationListener） - Messaging and Internationalization(
LocaleResolver） - Environment abstraction (after SpringFramework 3.1)
Q: How does dependency injection work? What’s the difference?
Note that this issue is also independent of the SpringFramework. The method of injection itself should be the implementation of dependency injection. As for the framework code, it is the implementation of this method.
It can be compared from the following dimensions:
| Injection pattern | Whether the injected member is mutable | Whether to rely on the API of the IOC framework | Usage scenarios |
|---|---|---|---|
| Constructor injection | immutable | No (XML, programmatic injection not dependent) | Immutable fixed injection |
| Parameters of the injection | immutable | Yes (intrusive injection can only be done by annotating) | Usually used for immutable fixed injection |
| Setter injection | variable | No (XML, programmatic injection not dependent) | Injection of optional properties |
Basically asking this question will probably lead to another question:
Which way do you think is better? Why is that?
“Mang fu” candidate a look finally to open the question, quickly began to play freely:
I think parameter injection is good, because I am used to writing, and how comfortable it is to annotate parameters!
You said it. What does the interviewer think: That’s it? Right here? And then you might have a negative impression of you.
This kind of problem, in addition to express subjective views, more is to support your opinion according to some existing arguments, the best argument must be the official documents.
The official documentation of the SpringFramework recommends different injection methods in different versions:
- SpringFramework 4.0.2 and before recommended setter injection because the constructor argument list can be long when a Bean has multiple dependencies. And if not all of the dependent properties in the Bean are required, injection becomes more cumbersome;
- Constructor injection is officially recommended in 4.0.3 and later because constructor injection dependencies are immutable, fully initialized, and guaranteed not to be null;
- As stated in 4.0.3 and later, if the constructor argument list is too long, it may be that the Bean is taking on too much responsibility and should consider component responsibility unpacking.
Q: What are the annotations for component injection? What’s the difference?
I’m sure most of you can answer @autowired and @Resource, so if you can answer these two, you’ve probably used them and you know how to use them. But prove that you know something about injected annotations by replying @inject. As a candidate, it is always best to answer questions as comprehensively as possible. Here is a comparison of these notes:
| annotations | Injection pattern | Whether @primary is supported | source | Processing if the Bean does not exist |
|---|---|---|---|---|
| @Autowired | Injection by type | is | SpringFramework native annotations | You can specify Required =false to avoid injection failures |
| @Resource | Injection by name | no | JSR specification | There is no specified Bean in the container that will throw an exception |
| @Inject | Injection by type | is | JSR330 specification (Guide JAR package required) | There is no specified Bean in the container that will throw an exception |
Similarly, if you ask this question, you are likely to be asked the following question:
How can injection be resolved when there are multiple beans of the same type?
Probably most of you can answer the following solutions:
@Resource: Specifies the injected Bean by name@Qualifier: cooperate with@AutowiredAnnotation uses, if the annotated member/method finds more than one Bean of the same type when injected by type, it looks for a particular Bean based on the name declared by the annotation@Primary: cooperate with@BeanAnnotation use, if there are multiple beans of the same type registered in the IOC container at the same time@Autowired、@InjectAnnotations are injected when annotated@PrimaryAnnotated beans
There is another option that you could propose: to inject the same field name as the bean name, which would also solve the problem of injecting a non-unique bean.
The above questions are some common questions about the SpringFramework and IOC. They are not unfamiliar, but you need to make efforts to answer them comprehensively and deeply. I hope you can gain something and answer fluently in the interview and get the offer!
It’s not easy to sort out the questions. Why don’t you support the author by clicking a “like”? (Pathetic)