Dependency Injection - Can It Be This Simple?

[Jordan S.]

Does the following accurately summarize the notion of "dependency
injection?"

Class A needs to cause "Some Activity" to happen (in addition to other
things that Class A does).

Class A may or may not have a default implementation of Some Activity.

Class B is able to do Some Activity.

At runtime, a reference to an instance of Class B is passed to Class A
(perhaps via Setter, or to the constructor of Class A).

Class A causes Some Activity to happen by calling a method of its Class B
reference.

In the future (or even immediately), we need for an alternative
implementation of Some Activity, so we create Class C.

We can then pass a reference [to a Class C instance] to Class A, which then
initiates Some Activity on the Class C instance.

In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that interface or
base class.

The most important benefit of the above arrangement (dependency injection)
is that we can extend the application specifically to perform alternative
implementations of Some Activity by adding a new class and updating the
application configuration (so that Class A can be passed a reference to the
new class), without modifying Class A in any way. In other words, Class A is
open for extension, but closed for modification, and dependency injection is
one way to achieve that objective.

Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection.

Thanks.

 

[Robbe Morris - [MVP] C#]

Are you able to just use interfaces and create a factory pattern?

http://www.eggheadcafe.com/articles/20031103.asp

--
Robbe Morris [Microsoft MVP - Visual C#]
AdvancedXL Server, Designer, and Data Analyzer
Convert cell ranges in Excel to rule driven web apps
without IT programmers.
Free download: http://www.equalssolved.com/default.aspx

 

[Jordan S.]

Your article is just freaking awesome and I think everybody in the entire
world should read it and send it to everybody they know.

Having said that, I'm still interested in getting some verification or
clarification of my understanding of dependency injection as a concept.

From the OP:
"Does the following accurately summarize the notion..."
"...as I'm wanting some verification or clarification of my understanding of
dependency injection."

I'm NOT asking whether I use a factory or should I use dependency injection
(a false dichotomy, I suspect, based on my entry-level understanding of
dependency injection).

Are you able to just use interfaces and create a factory pattern?

http://www.eggheadcafe.com/articles/20031103.asp

--
Robbe Morris [Microsoft MVP - Visual C#]
AdvancedXL Server, Designer, and Data Analyzer
Convert cell ranges in Excel to rule driven web apps
without IT programmers.
Free download: http://www.equalssolved.com/default.aspx

Does the following accurately summarize the notion of "dependency
injection?"

Class A needs to cause "Some Activity" to happen (in addition to other
things that Class A does).

Class A may or may not have a default implementation of Some Activity.

Class B is able to do Some Activity.

At runtime, a reference to an instance of Class B is passed to Class A
(perhaps via Setter, or to the constructor of Class A).

Class A causes Some Activity to happen by calling a method of its Class B
reference.

In the future (or even immediately), we need for an alternative
implementation of Some Activity, so we create Class C.

We can then pass a reference [to a Class C instance] to Class A, which
then initiates Some Activity on the Class C instance.

In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that interface
or base class.

The most important benefit of the above arrangement (dependency
injection) is that we can extend the application specifically to perform
alternative implementations of Some Activity by adding a new class and
updating the application configuration (so that Class A can be passed a
reference to the new class), without modifying Class A in any way. In
other words, Class A is open for extension, but closed for modification,
and dependency injection is one way to achieve that objective.

Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection.

Thanks.

 

[Family Tree Mike]

I believe you are just describing what interfaces are intended to achieve for
classes. From what I see in Wikipedia, there is a definition that agrees
with you, so, your example fits the definition.

What Robbe Morris may have been trying to say is, as I believe, that this
just means that Class A cares that Class B and Class C both impliment some
common interface. Unless I am missing something, it does not sound more
sophisticated than that.

 

[Robbe Morris - [MVP] C#]

You can also load assemblies dynamically at runtime. You can also
write code, compile it, assign references at runtime. Each has
performance implications.

There are ways to address performance issues mentioned in this
article but they are considered proprietary techniques in one of my
company's applications. So, I can't make that public.

http://www.eggheadcafe.com/articles/aspnet_dynamic_code_runtime.asp

This one may also prove useful...

http://www.eggheadcafe.com/tutorial...8-10ac501f430a/obfuscation-and-packaging.aspx

As to the factory pattern, that article certainly isn't ground breaking.
That is standard OOP explained in great detail for new folks to OOP.

As for dynamic references to an assembly, how would class A ever
be compiled if a reference "needed" to be added at runtime versus
simply recompiling the project at design time with the new assembly
added as a reference?

--
Robbe Morris [Microsoft MVP - Visual C#]
AdvancedXL Server, Designer, and Data Analyzer
Convert cell ranges in Excel to rule driven web apps
without IT programmers.
Free download: http://www.equalssolved.com/default.aspx

Your article is just freaking awesome and I think everybody in the entire
world should read it and send it to everybody they know.

Having said that, I'm still interested in getting some verification or
clarification of my understanding of dependency injection as a concept.

From the OP:
"Does the following accurately summarize the notion..."
"...as I'm wanting some verification or clarification of my understanding
of dependency injection."

I'm NOT asking whether I use a factory or should I use dependency
injection (a false dichotomy, I suspect, based on my entry-level
understanding of dependency injection).

Are you able to just use interfaces and create a factory pattern?

http://www.eggheadcafe.com/articles/20031103.asp

--
Robbe Morris [Microsoft MVP - Visual C#]
AdvancedXL Server, Designer, and Data Analyzer
Convert cell ranges in Excel to rule driven web apps
without IT programmers.
Free download: http://www.equalssolved.com/default.aspx

Does the following accurately summarize the notion of "dependency
injection?"

Class A needs to cause "Some Activity" to happen (in addition to other
things that Class A does).

Class A may or may not have a default implementation of Some Activity.

Class B is able to do Some Activity.

At runtime, a reference to an instance of Class B is passed to Class A
(perhaps via Setter, or to the constructor of Class A).

Class A causes Some Activity to happen by calling a method of its Class
B reference.

In the future (or even immediately), we need for an alternative
implementation of Some Activity, so we create Class C.

We can then pass a reference [to a Class C instance] to Class A, which
then initiates Some Activity on the Class C instance.

In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that
interface or base class.

The most important benefit of the above arrangement (dependency
injection) is that we can extend the application specifically to perform
alternative implementations of Some Activity by adding a new class and
updating the application configuration (so that Class A can be passed a
reference to the new class), without modifying Class A in any way. In
other words, Class A is open for extension, but closed for modification,
and dependency injection is one way to achieve that objective.

Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection.

Thanks.

 

[Jordan S.]

Thanks Mike and Robbe for taking a shot at answering my question.

I'm not sure where I went wrong in my OP - but I'm not asking about
alternatives or implemenation issues. In fact, I have no specific
programming task that I am asking for help with. What I was hoping for was
one (or more) of you OOP experts to either (1) give me a nod and say "yes
you do have a good understanding of this *concept* we call "dependency
injection."; or (2) "no, you are missing the boat... dependency injection is
actually xyz...".

By analogy, I was asking "is this a spoon"? ... fully expecting someone to
say, (1) "yup"; or (2) "nope".

But what I got was something like, "read my article about dinnerware
manufacturing."... then a followup of "geeze, you may have issues if you try
to use a spoon, you could use a fork and a knife as well, and maybe some
plates." I'm still wondering if it's a spoon.

I would restate my OP here to clarify, but I believe it is perfectly clear.
Oh well... I'm still hoping someone who knows what "dependency injection" is
can verify my understanding of it as I described it in the OP.

-Jordan.

I believe you are just describing what interfaces are intended to achieve
for
classes. From what I see in Wikipedia, there is a definition that agrees
with you, so, your example fits the definition.

What Robbe Morris may have been trying to say is, as I believe, that this
just means that Class A cares that Class B and Class C both impliment some
common interface. Unless I am missing something, it does not sound more
sophisticated than that.

Does the following accurately summarize the notion of "dependency
injection?"

Class A needs to cause "Some Activity" to happen (in addition to other
things that Class A does).

Class A may or may not have a default implementation of Some Activity.

Class B is able to do Some Activity.

At runtime, a reference to an instance of Class B is passed to Class A
(perhaps via Setter, or to the constructor of Class A).

Class A causes Some Activity to happen by calling a method of its Class B
reference.

In the future (or even immediately), we need for an alternative
implementation of Some Activity, so we create Class C.

We can then pass a reference [to a Class C instance] to Class A, which
then
initiates Some Activity on the Class C instance.

In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that interface
or
base class.

The most important benefit of the above arrangement (dependency
injection)
is that we can extend the application specifically to perform alternative
implementations of Some Activity by adding a new class and updating the
application configuration (so that Class A can be passed a reference to
the
new class), without modifying Class A in any way. In other words, Class A
is
open for extension, but closed for modification, and dependency injection
is
one way to achieve that objective.

Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection.

Thanks.

 

[Misbah Arefin]

http://en.wikipedia.org/wiki/Dependency_injection
If I understand what is mentioned in the above article correctly then YES
you have a good understanding of "spoon" err "dependency injection"


--
Misbah Arefin

Thanks Mike and Robbe for taking a shot at answering my question.

I'm not sure where I went wrong in my OP - but I'm not asking about
alternatives or implemenation issues. In fact, I have no specific
programming task that I am asking for help with. What I was hoping for was
one (or more) of you OOP experts to either (1) give me a nod and say "yes
you do have a good understanding of this *concept* we call "dependency
injection."; or (2) "no, you are missing the boat... dependency injection
is actually xyz...".

By analogy, I was asking "is this a spoon"? ... fully expecting someone
to say, (1) "yup"; or (2) "nope".

But what I got was something like, "read my article about dinnerware
manufacturing."... then a followup of "geeze, you may have issues if you
try to use a spoon, you could use a fork and a knife as well, and maybe
some plates." I'm still wondering if it's a spoon.

I would restate my OP here to clarify, but I believe it is perfectly
clear. Oh well... I'm still hoping someone who knows what "dependency
injection" is can verify my understanding of it as I described it in the
OP.

-Jordan.

I believe you are just describing what interfaces are intended to achieve
for
classes. From what I see in Wikipedia, there is a definition that agrees
with you, so, your example fits the definition.

What Robbe Morris may have been trying to say is, as I believe, that this
just means that Class A cares that Class B and Class C both impliment
some
common interface. Unless I am missing something, it does not sound more
sophisticated than that.

Does the following accurately summarize the notion of "dependency
injection?"

Class A needs to cause "Some Activity" to happen (in addition to other
things that Class A does).

Class A may or may not have a default implementation of Some Activity.

Class B is able to do Some Activity.

At runtime, a reference to an instance of Class B is passed to Class A
(perhaps via Setter, or to the constructor of Class A).

Class A causes Some Activity to happen by calling a method of its Class
B
reference.

In the future (or even immediately), we need for an alternative
implementation of Some Activity, so we create Class C.

We can then pass a reference [to a Class C instance] to Class A, which
then
initiates Some Activity on the Class C instance.

In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that
interface or
base class.

The most important benefit of the above arrangement (dependency
injection)
is that we can extend the application specifically to perform
alternative
implementations of Some Activity by adding a new class and updating the
application configuration (so that Class A can be passed a reference to
the
new class), without modifying Class A in any way. In other words, Class
A is
open for extension, but closed for modification, and dependency
injection is
one way to achieve that objective.

Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection.

Thanks.

 

[Sergey Zyuzin]

Does the following accurately summarize the notion of "dependency
injection?"

Class A needs to cause "Some Activity" to happen (in addition to other
things that Class A does).

Class A may or may not have a default implementation of Some Activity.

Class B is able to do Some Activity.

At runtime, a reference to an instance of Class B is passed to Class A
(perhaps via Setter, or to the constructor of Class A).

Class A causes Some Activity to happen by calling a method of its Class B
reference.

In the future (or even immediately), we need for an alternative
implementation of Some Activity, so we create Class C.

We can then pass a reference [to a Class C instance] to Class A, which then
initiates Some Activity on the Class C instance.

In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that interface or
base class.

The most important benefit of the above arrangement (dependency injection)
is that we can extend the application specifically to perform alternative
implementations of Some Activity by adding a new class and updating the
application configuration (so that Class A can be passed a reference to the
new class), without modifying Class A in any way. In other words, Class A is
open for extension, but closed for modification, and dependency injection is
one way to achieve that objective.

Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection.

Thanks.

Hi,

I'll explain how I understand Dependency Injection (I'm referring to
Martin Fowler's definitions).
The essentials of DI is that process of configuring of components
shall be separated from their use.

Dependency Injection implies existence of some assembler that sets
dependencies (ClassB is somehow passed to ClassA, via constructor, or
property or interface injection). This assembler can be either a
component that parses some configuration (XML configuration for
example like many containers do), instantiates objects and sets
dependencies. Or it can be written explicitly in your programming
language.

So, if you have such assembler, then you have Dependency Injection

Thanks,
Sergey

 

[Family Tree Mike]

I believe what I said was "yup".

I added, that any class that accepts an object implimenting an interface
also seems to fit the definition. I'm sorry for providing too much info.

Thanks Mike and Robbe for taking a shot at answering my question.

I'm not sure where I went wrong in my OP - but I'm not asking about
alternatives or implemenation issues. In fact, I have no specific
programming task that I am asking for help with. What I was hoping for was
one (or more) of you OOP experts to either (1) give me a nod and say "yes
you do have a good understanding of this *concept* we call "dependency
injection."; or (2) "no, you are missing the boat... dependency injection is
actually xyz...".

By analogy, I was asking "is this a spoon"? ... fully expecting someone to
say, (1) "yup"; or (2) "nope".

But what I got was something like, "read my article about dinnerware
manufacturing."... then a followup of "geeze, you may have issues if you try
to use a spoon, you could use a fork and a knife as well, and maybe some
plates." I'm still wondering if it's a spoon.

I would restate my OP here to clarify, but I believe it is perfectly clear.
Oh well... I'm still hoping someone who knows what "dependency injection" is
can verify my understanding of it as I described it in the OP.

-Jordan.

I believe you are just describing what interfaces are intended to achieve
for
classes. From what I see in Wikipedia, there is a definition that agrees
with you, so, your example fits the definition.

What Robbe Morris may have been trying to say is, as I believe, that this
just means that Class A cares that Class B and Class C both impliment some
common interface. Unless I am missing something, it does not sound more
sophisticated than that.

Does the following accurately summarize the notion of "dependency
injection?"

Class A needs to cause "Some Activity" to happen (in addition to other
things that Class A does).

Class A may or may not have a default implementation of Some Activity.

Class B is able to do Some Activity.

At runtime, a reference to an instance of Class B is passed to Class A
(perhaps via Setter, or to the constructor of Class A).

Class A causes Some Activity to happen by calling a method of its Class B
reference.

In the future (or even immediately), we need for an alternative
implementation of Some Activity, so we create Class C.

We can then pass a reference [to a Class C instance] to Class A, which
then
initiates Some Activity on the Class C instance.

In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that interface
or
base class.

The most important benefit of the above arrangement (dependency
injection)
is that we can extend the application specifically to perform alternative
implementations of Some Activity by adding a new class and updating the
application configuration (so that Class A can be passed a reference to
the
new class), without modifying Class A in any way. In other words, Class A
is
open for extension, but closed for modification, and dependency injection
is
one way to achieve that objective.

Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection.

Thanks.

 

[Bill Woodruff]

Jordan S. wrote :

"Does the following accurately summarize the notion of "dependency
injection?"

.... example snipped for brevity ...

Yes, I think in a narrow "literal" technical sense it does.

But I think the form of the question is somewhat muddled. You do not specify
where the code is that decides whether Class A is going to call on Class B
or Class C and "does the right thing" to insert the reference into Class A.
That's really the critical question, imho.

imho the .NET way is to have Class A raise an Event which will call some
over-arching program structure (Controller in MVC paradigm) which will take
into account whatever conditions and set the reference in Class A so it
invokes the required functionality. Even more esoteric approaches are
possible : this master-thingee that decides where Class A should get its
functionality can change the subscribers to the Event raised by Class A,
effectively dis-connecting B from listening to A's event, and turning on C's
listening to A's event. Or, as needed, allowing both B and C to be called,
or disconnecting them all. That's the power of event multi-casting.

"Dependency Injection" as I have seen it practiced in the .NET world has
been more the case where at run-time references to other objects are
permanently (i.e., for the life of the application) inserted into other
classes, winforms, or run-time created forms or objects. Mainly to eliminate
look-ups and casting. For example : Form2 has a variable of type Form1:

// in Form 2
public Form1 myForm1;

And when a new instance of Form2 is created by some action in Form1, Form1
does something like this :

// in Form1
Form2 newForm2 = new Form2();
newForm2.myForm1 = this;

Obviously this case would be one in which Form1 is not the parent of Form2,
because then you could just call Form2.Parent to have access to it.

"In the above account, Class B and Class C both implement an interface or
derive from a common abstract base class -- and Class A knows only about
that interface, and initiates Some Activity as a method of that interface or
base class."

This seems a digression from the example in the sense that, after all, Class
A could invoke the functionality it needed from any source that was valid
whose reference was "injected" into A. What do you mean when you say "Class
A" "knows only about" the interface : do you mean that at run-time when
Class A goes to use this functionality located elsewhere it's going to do a
check to make sure the reference it has is to a class that implemented that
interface :

if(! myFunctionReference is IGoodSource){
// ... throw an error ?
}
else {
// invoke the function you need here ...
}

You lose me a little there.

"The most important benefit of the above arrangement (dependency injection)
is that we can extend the application specifically to perform alternative
implementations of Some Activity by adding a new class and updating the
application configuration (so that Class A can be passed a reference to the
new class), without modifying Class A in any way. In other words, Class A is
open for extension, but closed for modification, and dependency injection is
one way to achieve that objective."

Technically correct. But there are many ways to that end. The "global issue"
you are discussing here is late binding vs. early binding. And there are
many tools in .NET that support that including Reflection, Delegates, etc.

"Your comments are appreciated, as I'm wanting some verification or
clarification of my understanding of dependency injection."

Then you ... are ... asking for more than "yup" and "nope"

best, Bill Woodruff