Dependency Injection In Spring Framework 

Disclaimer Presentations are intended for educational purposes only and not to replace independent professional judgement. The views and opinions expressed in this prsentation do not necessarily reflect the official policy or position of blibli.com. Audience discretion is advised. 

Who am I? • Alex Xandra Albert Sim • Lead Principal Engineer at Blibli.com • Mostly working at developer experience related stuff • bertzzie(.sim) 

Dependency Injection: What and Why 

Let’s see some code! 

Takeaway from the Code • Maintaining dependencies and relationships between classes is hard • More code == More challenges • Factory pattern could be a solution on the “how to create object” part, but not a solution on “I want different implementations for different situation” part 

Let’s see how spring do it! 

What did I just see?! The 4 components of a dependency injection system: 1. Service – the object that we wants to use (inject) 2. Client – the object that is depending on service 3. Interface – same concept as Interface in OOP 4. Injector – a system that’s responsible for creating and injecting services / clients 

Here: - SpeakServiceImpl is a Client - MessageService is a Service 

Here: - The highlighted code is the Injector - This is not actually the recommended way to do this in Spring, but simple enough as an example - We’ll see the “right way” later 

Here: - We use a feature called “Field Injection” - @Autowired means that Spring will automatically inject this dependency - There are other kinds of technique that Spring uses. More on this later. 

Understanding the Log [main] DEBUG org.springframework.beans.factory.support.DefaultListableBeanFactory - Creating shared instance of singleton bean 'speakService' Here: - Shared instance means that whenever you use a ‘speakService’, it will be the same instance - Notice how we never name those beans, but it automatically have name - Spring store those dependencies in a key-value pair map 

Spring ApplicationContext 

Best Practices If not BeanFactory, then what? Let’s see some code! 

Here: - It’s basically the same, even the same Constructor (AnnotationConfigApplicationContext)! - Why ApplicationContext? 

Spring ApplicationContext • Is a superset of BeanFactory • Have more features than a simple bean initialization • For example: events, lifecycle, message source (i18n), etc • Is what you automatically use in Spring / SpringBoot by default 

ApplicationContext vs BeanFactory Source: https://docs.spring.io/spring/docs/current/spring-framework- reference/core.html#context-introduction-ctx-vs-beanfactory 

Spring IoC • With Spring, you will not create objects (with configuration) manually most of the time • You describe how and when to create object in one place, Spring took care of the rest • The control of object creation is no longer in your hand but Spring’s, hence Inversion of Control 

Types of Injection in Spring 

We have seen this and said that this is “not recommended”. Why? 1. This uses reflection. It’s costly performance wise. 2. Too easy adding dependencies this way, and it usually leads to maintainability problem. - Could “accidentally” violate Single Responsibility Principle - No one likes to maintain a 1000s lines of class with the first 100s lines being @Autowired Field Injection 

Let’s find another way to do it! 

Constructor Injection Notice how: - we have @Autowired on Constructor - @Autowired is actually optional - Spring know how to create the object on the Configuration class 

Setter Injection Notes: - We don’t have @Autowired here - General guideline: Constructor injection for mandatory dependency, Setter injection for optional dependency. 

Final Notes 

What we missed L • Multiple Beans of the same type • Lazy initialization • Autowiring types • Debugging bean dependency issue in Spring 

Code at: https://github.com/bertzzie/di-in-spring Slides at: https://speakerdeck.com/bertzzie/dependency-injection-in-spring QA and Closing