1

00:00:00.06 --> 00:00:02.09

- [Lecturer] As I mention, the Inversion of Control pattern



2

00:00:02.09 --> 00:00:05.05

is a core pattern in the Spring Framework.



3

00:00:05.05 --> 00:00:08.05

And in my opinion, is the core pattern



4

00:00:08.05 --> 00:00:11.04

for for all of Spring's operational behavior.



5

00:00:11.04 --> 00:00:14.05

Now, let's talk a little bit about what IoC is.



6

00:00:14.05 --> 00:00:16.00

As I alluded to before,



7

00:00:16.00 --> 00:00:19.00

it is not a Gang of Four design pattern.



8

00:00:19.00 --> 00:00:22.06

But nonetheless, this is architectural pattern



9

00:00:22.06 --> 00:00:26.09

for relegating control of dependencies to the container



10

00:00:26.09 --> 00:00:30.03

instead of the developer having to be responsible



11

00:00:30.03 --> 00:00:33.00

for the construction of those dependencies.



12

00:00:33.00 --> 00:00:36.06

Now, often this is called Dependency Injection,



13

00:00:36.06 --> 00:00:40.03

though, that is only one flavor of IoC.



14

00:00:40.03 --> 00:00:42.06

Now, I tend to make that mistake



15

00:00:42.06 --> 00:00:45.03

and call IoC and Dependency injection the same thing,



16

00:00:45.03 --> 00:00:46.09

and that's just natural,



17

00:00:46.09 --> 00:00:48.08

because from a Spring Framework perspective,



18

00:00:48.08 --> 00:00:52.05

Dependency Injection is one of the primary benefits



19

00:00:52.05 --> 00:00:55.04

of using the IoC pattern.



20

00:00:55.04 --> 00:00:58.05

And next to one of most develpers actually interact with



21

00:00:58.05 --> 00:01:01.00

on a regular basis.



22

00:01:01.00 --> 00:01:03.04

Now, let's talk a little bit about how it works.



23

00:01:03.04 --> 00:01:06.08

A central container constructs



24

00:01:06.08 --> 00:01:09.06

and maintains all objects references



25

00:01:09.06 --> 00:01:13.02

and subsequent state of those objects.



26

00:01:13.02 --> 00:01:18.00

When another component within the ecosystem needs an object,



27

00:01:18.00 --> 00:01:21.00

the IoC container hands it to them



28

00:01:21.00 --> 00:01:24.00

at runtime or at start up.



29

00:01:24.00 --> 00:01:25.09

This provides centralized control,



30

00:01:25.09 --> 00:01:29.09

and management for all objects in the runtime.



31

00:01:29.09 --> 00:01:31.09

Now, in Spring,



32

00:01:31.09 --> 00:01:34.03

the IoC container



33

00:01:34.03 --> 00:01:36.07

manages all of your dependencies,



34

00:01:36.07 --> 00:01:39.08

at least the one that you hand to Spring.



35

00:01:39.08 --> 00:01:42.04

So, it will not manage those dependencies



36

00:01:42.04 --> 00:01:43.07

that you don't ask it to,



37

00:01:43.07 --> 00:01:46.05

but once you ask it to manage a dependency,



38

00:01:46.05 --> 00:01:50.07

it will do so to the life cycle of the application,



39

00:01:50.07 --> 00:01:53.06

and not allow them to be destroyed until



40

00:01:53.06 --> 00:01:56.08

it goes into its shutdown routine.



41

00:01:56.08 --> 00:01:58.01

There is an exception to this,



42

00:01:58.01 --> 00:01:59.08

and that is the way the prototypes work,



43

00:01:59.08 --> 00:02:02.00

but we'll talk about that when we get there.



44

00:02:02.00 --> 00:02:04.06

Objects are injected at runtime,



45

00:02:04.06 --> 00:02:06.09

not at compile time.



46

00:02:06.09 --> 00:02:08.03

Now, what do I mean by that?



47

00:02:08.03 --> 00:02:11.01

When you're writing a traditional application



48

00:02:11.01 --> 00:02:13.02

and not using IoC,



49

00:02:13.02 --> 00:02:15.00

you construct the object



50

00:02:15.00 --> 00:02:18.00

and inject it in your code.



51

00:02:18.00 --> 00:02:22.02

In Spring, the objects are constructed at startup



52

00:02:22.02 --> 00:02:24.02

and injected into the runtime,



53

00:02:24.02 --> 00:02:27.06

so the developer doesn't really have to deal with them



54

00:02:27.06 --> 00:02:31.01

when they're actually writing and compiling their code.



55

00:02:31.01 --> 00:02:35.00

An object accepts the dependencies for construction



56

00:02:35.00 --> 00:02:38.04

instead of you constructing them.



57

00:02:38.04 --> 00:02:41.09

Now, in reality, you still have to tell Spring



58

00:02:41.09 --> 00:02:45.06

how to construct your objects under many circumstances,



59

00:02:45.06 --> 00:02:47.07

but you only do it once



60

00:02:47.07 --> 00:02:50.02

instead of lettering it throughout your code,



61

00:02:50.02 --> 00:02:52.02

and that's where IoC has power.



62

00:02:52.02 --> 00:02:54.03

So, what are some of the benefits of IoC



63

00:02:54.03 --> 00:02:56.01

and the ones that we care about?



64

00:02:56.01 --> 00:03:00.00

First and foremost, it reduces noise in your code.



65

00:03:00.00 --> 00:03:04.06

Consider the consequence of creating a JDBC connection



66

00:03:04.06 --> 00:03:07.00

for instance everywhere in your application,



67

00:03:07.00 --> 00:03:10.00

where you make a connection to the database.



68

00:03:10.00 --> 00:03:13.07

That can get really, really loud from a code perspective,



69

00:03:13.07 --> 00:03:15.06

and when you think about the fact



70

00:03:15.06 --> 00:03:17.03

that all of that's boilerplate,



71

00:03:17.03 --> 00:03:19.03

yeah, we'll talk about that with the template pattern.



72

00:03:19.03 --> 00:03:22.07

But the point is that when you use IoC,



73

00:03:22.07 --> 00:03:24.09

because you're not constructing those objects,



74

00:03:24.09 --> 00:03:27.04

you reduce the noise in your code,



75

00:03:27.04 --> 00:03:30.09

it also reduces object coupling,



76

00:03:30.09 --> 00:03:34.03

because you are handed a dependency into your object,



77

00:03:34.03 --> 00:03:36.07

you're not as tightly coupled to it,



78

00:03:36.07 --> 00:03:40.03

because you actually don't need to know how it's constructed



79

00:03:40.03 --> 00:03:44.03

at compiled time or at writing of code time.



80

00:03:44.03 --> 00:03:46.06

It also reduces the defects



81

00:03:46.06 --> 00:03:49.04

that arrives from incorrect construction.



82

00:03:49.04 --> 00:03:50.09

Now what do I mean by that?



83

00:03:50.09 --> 00:03:52.07

Normally when we construct an object,



84

00:03:52.07 --> 00:03:55.05

we write a new line and then we construct the object



85

00:03:55.05 --> 00:03:57.02

and add everything that we mean,



86

00:03:57.02 --> 00:03:59.09

and then next time that we need to construct that object,



87

00:03:59.09 --> 00:04:02.07

we tend to copy and paste,



88

00:04:02.07 --> 00:04:05.08

and while that may seem okay in some circumstances,



89

00:04:05.08 --> 00:04:08.05

that does cause defects to arise,



90

00:04:08.05 --> 00:04:09.06

you missed a line,



91

00:04:09.06 --> 00:04:11.06

you needed to change a value,



92

00:04:11.06 --> 00:04:15.03

something is different, and when you copy paste,



93

00:04:15.03 --> 00:04:16.09

you ask for defects,



94

00:04:16.09 --> 00:04:19.06

that's just the nature of software development.



95

00:04:19.06 --> 00:04:22.08

So, because the IoC container handles all of construction,



96

00:04:22.08 --> 00:04:25.05

you reduce those defects that arise



97

00:04:25.05 --> 00:04:28.01

from the construction itself.



98

00:04:28.01 --> 00:04:31.04

Now, the core is the Application Context.



99

00:04:31.04 --> 00:04:35.05

Spring's Application Context is the IoC Container,



100

00:04:35.05 --> 00:04:37.08

another pattern is also in play,



101

00:04:37.08 --> 00:04:38.07

and we're going to talk about that



102

00:04:38.07 --> 00:04:40.03

and that is the Bean Factory,



103

00:04:40.03 --> 00:04:42.04

which leverages the factory pattern.



104

00:04:42.04 --> 00:04:47.08

But again, the Ioc container is the Application Context



105

00:04:47.08 --> 00:04:51.06

and it leverages configuration to create the beans



106

00:04:51.06 --> 00:04:54.00

and manage the dependency injections.



107

00:04:54.00 --> 00:04:57.04

Now, truly understanding dependency injection,



108

00:04:57.04 --> 00:05:00.07

and inversion of control, and how the Application Context



109

00:05:00.07 --> 00:05:03.01

comes into play in a Spring application,



110

00:05:03.01 --> 00:05:05.06

is beyond the scope of this course.



111

00:05:05.06 --> 00:05:09.02

But I have another course in the library called



112

00:05:09.02 --> 00:05:11.01

Spring: Framework in Depth



113

00:05:11.01 --> 00:05:13.06

that I highly encourage you to check out,



114

00:05:13.06 --> 00:05:16.01

because it's actually going to talk about how



115

00:05:16.01 --> 00:05:17.07

the Application Context is configured,



116

00:05:17.07 --> 00:05:21.09

and how it's used through the lifecycle of the application.



