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.
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
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
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
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
(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
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