|
Maybe this will help. IoC is a design/architecture concept, DI is an implementation approach. With IoC your are doing structural inversion on object lifecycles. Commonly an operating object will "new" any objects it needs and then invoke operations. With IoC the objects are supplied and the operating object invokes operations on this supplied object. So, behavior lives in the operating object, but the structure has been factored out to a higher level - inverted. Since Interfaces define behavior, they are a common construct in IoC/DI. The simplest implementation of IoC doesn't need DI. This is IoC:
Class Foo {
public string Bar(Decoder decoder, string inString){ return decoder.decode(inString); }
}
You have inverted control of lifecycle management. The caller creates and supplies the structure (the object doesn't "new" any ones it wants), and the operating object operates on these objects.
More commonly, you do this in the constructor.
Class Foo {
readonly Decoder _decoder;
public Foo(Decoder decoder){
_decoder = decoder;
}
public string Bar(string inString){ return _decoder.decode(inString); }
}
In some ways, the operating object is less dependent because it doesn't have to manage the selection and lifecycle management of the used object. This is IoC (hard coded) in a nutshell.
DI is one way to address hard coding. You can think of DI as a combined Lookup and Activator. You give DI a "key", it looks up the mapped object, instantiates it using an Activator, and passes out the instance. You can have 1:1 type situations, where the Key and Value are the same. I tell it Foo, and it gives me a Foo object. Or, you can have 1:Many. Interfaces help here. Because with IoC I have decoupled the structure from the behavior, and interfaces are about behavior, I can associate many Values with a Key.
interface IFoo {
string Bar(string inString);
}
class FooOne : IFoo { }
class FooTwo : IFoo { }
lookup.Add(IFoo, FooOne);
lookup.Add(IFoo, FooTwo);
This provides another form of loosening dependencies and coupling.
class Foo{
IFoo _foo;
public Foo(IFoo foo){ _foo = foo }
}
The DI system "intercepts" object creation, inspects the constructor to see if any types are in the lookup, supplies those instances, and then lets the creation process resume.
To your question about "new", with "new" I have to know the class and it's details. Here I just need to know the (usually smaller) set of relevant methods on an interface. In theory, the DI system could randomly pick FooOne or FooTwo, and things should work the same. Of course, there is a lot more to this.
So, "less dependent" begs, "In what way?". From the perspective of having to know about all of the methods, we can use interfaces to minimize the set of those we need to know. A class may have 100 methods, but if IFoo only has one, we can use the class and completely ignore the other 99. Or I can use "best fit" implementations - one implementation (FooOne) may work better with small data sets, and one (FooTwo) with large data sets. I can swap them in and out in real time using DI, never touching a "new FooXxx()". Better though, is (conceptually) we can design code without ever thinking about implementation. We have factored out structure (and it's implementation), and deal only with behavior. You could write an entire application using only interfaces and test stubs. Then you could build/modify/buy classes that implement those interfaces. You could plug them in manually or use a DI system to do it dynamically.
|
|
|
|
|
If you drive a VW full of plantain into a hill of pasta, do you get Spaghetti Carbanana?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Can't think about stuff like that now. My girlfriend left me because of my obsession with pasta – I’m doing well, but feeling cannelloni.
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
This morning pastina hurry, but as for your question, I'll know in a day orzo.
Is a obsessive attraction to small feet a fettuccine?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
OriginalGriff wrote: If you drive a VW
Diesel too pass.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
"Berlin to Warsaw on one tank." -- JC
|
|
|
|
|
Griff you are always good for a fusilli puns.
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
...if you listen varicosely?
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
|
O really?
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
A sanguine remark?
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
You bloody well know that!
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
All puns aside, I can. It is encoded in my tinitus...
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Make two of them
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Do you have to go for the cheap puns...
just because blood sells?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Sorry - It was the best pun I could afford today...
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
Yeah, that one was pretty bad. Might have to call Interpol on you. Start running...
|
|
|
|
|
Hi All,
Jira a wonderful system for bug & issue tracking... However if you take a couple of days off you get buried with tickets. Most of the tickets I have come across are asking me why I haven't resolved an issue raised by another ticket, which was raised by another ticket and on... Much digital digging turns out that it was an issue that I had fixed just after it came to light marked it on the fix sheet. However as it was marked as fixed to make someone happy a fault had to be raised in Jira, which generated a 'number' which had to have the 'code' applied to it generated by the 'Zephyr' thing.
Good Grief! I spent over an hour to find I had done what was the cause of this thing to work 'Smarter, not harder'
I had better end there tickets are piling up!!
|
|
|
|
|
Perhaps it should be renamed. How about 'Avalanche'?
Edit: Or 'Snowball'?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
I don't care what its called, it gets in the elephanting way! You spend more time trying to tell the system you are doing your job than do doing it!!
|
|
|
|
|
glennPattonWork wrote: work 'Smarter, not harder'
Be smarter, not work harder.
I would suggest delegate, delete or disable.
|
|
|
|
|
Oooh how I wish I could... new company new rules...
|
|
|
|
|
Hmmm... you talk as if you were blaming Jira, and not the way your company uses it.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
True, I think it for use in software development is good, however trying shoe horn Hardware into is asking for trouble...
|
|
|
|
|
Why? Don't both hardware and software implement algorithms? Why should then so different approaches be needed that shoehorning is required?
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|