Lecture 8: Dependency Injection

Loading...

From the course by Johns Hopkins University

Single Page Web Applications with AngularJS

1362 ratings

Johns Hopkins University

Single Page Web Applications with AngularJS

1362 ratings

Course 5 of 6 in the Specialization Ruby on Rails Web Development

Do you want to write powerful, maintainable, and testable front end applications faster and with less code? Then consider joining this course to gain skills in one of the most popular Single Page Application (SPA) frameworks today, AngularJS. Developed and backed by Google, AngularJS is a very marketable skill to acquire. In this course, we will explore the core design of AngularJS 1.x (latest version of AngularJS 1), its components and code organization techniques. We will enhance the functionality of our web app by utilizing dependency injection to reuse existing services as well as write our own. We will create reusable HTML components that take advantage of AngularJS data binding as well as extend HTML syntax with a very powerful feature of AngularJS called directives. We’ll set up routing so our SPA can have multiple views. We will also learn how to unit test our functionality. At the end of this course, you will build a fully functional, well organized and tested web application using AngularJS and deploy it to the cloud.

From the lesson

Introduction to AngularJS

In this module, we are going to start by going over how grading works for this course, will introduce some recommended books, as well as give you the information on how to find all of the source code that you will see throughout the course. We will then dive into the development environment setup for both Mac and Windows. The core of this module will be the introduction not only to the basics of AngularJS, but more importantly, the concepts that back AngularJS as a good solution for developing front-end web applications. To become a good software developer and not just with AngularJS, you will need to understand these concepts. But for becoming a good AngularJS developer, these concepts are essential, because they will allow you to understand the issues the framework is addressing and therefore get a good grasp on the solutions AngularJS is offering.

Lecture 8: Dependency Injection6:38

Lecture 9: How Dependency Injection Works in Javascript8:17

Lecture 10: Protecting Dependency Injection from Minification10:19

Lecture 11, Part 1: Expressions and Interpolation8:17

Lecture 11, Part 2: Expressions and Interpolation7:08

Module 1 Wrap-up0:57

Meet the Instructors

Yaakov Chaikin
Adjunct Professor, Graduate Computer Science
Whiting School of Engineering

[SOUND] In this lecture,

we're going to speak about one more very important concept that is actually

used throughout AngularJS, and that is dependency injection.

I'm sure by now you have seen this construct where we create the module

that we're going to use in AngularJS, and we also create the controller

with an associated function that is responsible for the functionality and

kind of the glue code of that controller to the view.

And you've seen the $scope that we pass into the controller's function,

but where does this $scope come from, who instantiated?

We've seen that when we do console.log on this $scope,

it's a pretty complex object, so who instantiates that object?

And the answer is that AngularJS instantiates this object for us, and

the way we get that object as part of our controller

is through something called dependency injection.

So, dependency injection is yet another design pattern.

We've seen one model view, ViewModel, and

now there's another called dependency injection.

So, it's a design pattern that implements something called inversion of control for

resolving dependencies.

So, inversion of controls is a construct or an approach for resolving dependencies.

To understand what inversion of control means, let's take a look at how we usually

go about architecting a couple of opponents in let's say a shopping cart.

So the regular control will be,

if we have a shopping cart, we can have a separate module called CardProcBank1,

basically a card processing, credit card processing for Bank1 module and

it has one method charge given the credit card number and the amount.

And the reason we have a credit card for a particular bank is because, for

that particular bank, we might have a particular URL that we have to contact

a bank through and that particular can have its API.

So we don't want to take all that code and stick it directly into the shopping cart

because our shopping cart would be very much and very closely tight.

Would have tight coupling with a particular bank API.

We don't want to do that.

So the way we would instantiate the cart processing,

is we would create that cart processing module inside shopping cart.

And then we'll just call charge, and

call charge giving it the number and the amount.

And clearly in this diagram, we see that the shopping cart module depends

on the card processing module for bank #1.

But what happens if tomorrow we decide that we don't like this bank,

and we want to use a different bank because it has better prices for For

credit card processing fees or something like that.

So the way we would do that is, we would have to write a separate card processing

bank 2 that also would have the same type of charge with the number and amount.

And in that case it means our shopping cart code will have to slightly change And

now when we create the instance of the credit card processing module,

we would have to create it with obviously credit card processing for Bank2.

And then as before,

we would call that charge method passing at the number and amount.

And here again you clearly see that the shopping cart

again depends on this card processing for Bank2 module.

But we have a huge problem here, we have to change the code

inside the shopping cart which means we have tight coupling again.

Just because we switched which bank we process our cards through

we need to change the code inside the shopping cart?

And how do you test the ShoppingCart?

Let's say you only have a couple of simple methods, add to card and remove from card,

in this scenario you wouldn't have to instantiate a whole credit

card processing system just to see if your cart, your ShoopingCart Can

place something into the right array and remove something from that array,

keeping counts of total value of the shopping cart, total taxes, and etc.

That would be insane.

We can of course create a fake credit card.

Processing module and instantiate that instead inside a shopping cart.

But that would once again require us to change the code in the shopping cart.

And having to temporarily change the code in the very function

that we're trying to test seems like a really backwards and a bad idea.

Who says we won't mess up something while changing the code for

the test, and then putting it back the way it was?

So what's the solution?

The solution is Inversion of Control.

And in this particular approach, our shopping cart functional module

accepts a credit card processing module Is an argument and we still have that

line where we call the charge method on that card processing module but

if now is using the instance that we were passed from somewhere else.

We get still have those separate modules but in this case, some Overall system

is going to be the one who is going to instantiate that credit card processing.

So in this case would instantiate the credit card processing for bank one.

And the system is going to call the shopping card passing it

the new instance of credit card processing for bank one.

So in this scenario if we need a different bank for card processing

the shopping cart code is left completely untouched it will not change.

This is by the way why IoC or

inversion of control Is sometimes jokingly called, don't call us, we'll call you.

Because as you could see,

the shopping cart no longer calls out to instantiate the card processing module,

but instead we, the system, calls the shopping cart module

providing the card processing instance to use inside of the shopping cart.

So just to summarize.

We learned yet another pattern called dependency injection for short it's called

DI dependency injection which implements an approach called inversion of control

and if you read things online or in other literature You'll see that inversion

control is often times referred to as IoC, Inversion of Control.

And in that approach,

client gets called with the dependencies by some other system.

And in our case,

obviously That other system that surrounding ecosystem is angular js.

And the whole point of it here is.

Is the client is not responsible for

istantiating the dependency that other code that it depends on.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play