Technical disussion about DI/DI Containers...
-
...DI (Dependency Injection) and especally DI Containers. I'm meanwhile tired of reading and thinking about it, or then most probably I still don't get the point on it. Basically, the concept of DI, I like it very much. It forces me to think about my design. And yes, it supports me to write (independent) unit tests. So far so good. But what I hate among others, is a sentence 'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English... Sorry, but at the end, when it comes to assemble to so called loose coupled things, it has to work with the implementation and not with the definition of the interface.... I think we always need a real test again, which tests the loose coupled thing against the concrete implementation. Where the hell I'm wrong?
-
...DI (Dependency Injection) and especally DI Containers. I'm meanwhile tired of reading and thinking about it, or then most probably I still don't get the point on it. Basically, the concept of DI, I like it very much. It forces me to think about my design. And yes, it supports me to write (independent) unit tests. So far so good. But what I hate among others, is a sentence 'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English... Sorry, but at the end, when it comes to assemble to so called loose coupled things, it has to work with the implementation and not with the definition of the interface.... I think we always need a real test again, which tests the loose coupled thing against the concrete implementation. Where the hell I'm wrong?
0x01AA wrote:
'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English...
The phrasing is awkward, even for an English speaker. Another way to phrase this would be: "Program according to an interface, rather than based on an implementation". Does this help?
Software Zen:
delete this; -
...DI (Dependency Injection) and especally DI Containers. I'm meanwhile tired of reading and thinking about it, or then most probably I still don't get the point on it. Basically, the concept of DI, I like it very much. It forces me to think about my design. And yes, it supports me to write (independent) unit tests. So far so good. But what I hate among others, is a sentence 'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English... Sorry, but at the end, when it comes to assemble to so called loose coupled things, it has to work with the implementation and not with the definition of the interface.... I think we always need a real test again, which tests the loose coupled thing against the concrete implementation. Where the hell I'm wrong?
"Program against" as in the context of defensive programming. He pretty well says "always use an interface" instead of the actual object (the implementation). Before "DI" we had parameterized constructors; which is now "DI"; that's why there's confusion. Making up words to fit the model.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
0x01AA wrote:
'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English...
The phrasing is awkward, even for an English speaker. Another way to phrase this would be: "Program according to an interface, rather than based on an implementation". Does this help?
Software Zen:
delete this; -
"Program against" as in the context of defensive programming. He pretty well says "always use an interface" instead of the actual object (the implementation). Before "DI" we had parameterized constructors; which is now "DI"; that's why there's confusion. Making up words to fit the model.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
...DI (Dependency Injection) and especally DI Containers. I'm meanwhile tired of reading and thinking about it, or then most probably I still don't get the point on it. Basically, the concept of DI, I like it very much. It forces me to think about my design. And yes, it supports me to write (independent) unit tests. So far so good. But what I hate among others, is a sentence 'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English... Sorry, but at the end, when it comes to assemble to so called loose coupled things, it has to work with the implementation and not with the definition of the interface.... I think we always need a real test again, which tests the loose coupled thing against the concrete implementation. Where the hell I'm wrong?
Think of "against" as in the context of a ladder leaning against a wall.
The difficult we do right away... ...the impossible takes slightly longer.
-
...DI (Dependency Injection) and especally DI Containers. I'm meanwhile tired of reading and thinking about it, or then most probably I still don't get the point on it. Basically, the concept of DI, I like it very much. It forces me to think about my design. And yes, it supports me to write (independent) unit tests. So far so good. But what I hate among others, is a sentence 'program against an interface and not against the implementation' (abstraction vs. implementation). Only the word 'against' is wrong in my understanding, but that is most probably my English... Sorry, but at the end, when it comes to assemble to so called loose coupled things, it has to work with the implementation and not with the definition of the interface.... I think we always need a real test again, which tests the loose coupled thing against the concrete implementation. Where the hell I'm wrong?
DI is overrated. Programming "to" an interface is fine when you have a real use case to abstract different implementations that you may want to switch between when service A (or controller A) needs to support service implementations S1, S2, and S3. For example, you might have several document store services, one for AWS buckets, one for your own document server, one for storing documents as blobs in a DB and different ones get instantiated on the fly depending on other factors. That said, one can code an application into interface hell, where everything has an interface and almost nothing needs an interface because there's only ever going to be one concrete implementation of the service. Happily, in .NET Core for example, the DI engine doesn't require interfaces - you can specify "this service is implemented by its concrete type" rather than always having to say "this service implements this interface." I have literally chucked out thousands of lines of interface code (I pity the programmer that wrote all that crap -- it wasn't me) because they were glommed onto the "DI must be done with interfaces" not realizing they were making pointless work for themselves because the never ever would have multiple concrete implementations for the interface abstraction. Know when to use an interface rather than always use an interface. Much like, um...
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain -
DI is overrated. Programming "to" an interface is fine when you have a real use case to abstract different implementations that you may want to switch between when service A (or controller A) needs to support service implementations S1, S2, and S3. For example, you might have several document store services, one for AWS buckets, one for your own document server, one for storing documents as blobs in a DB and different ones get instantiated on the fly depending on other factors. That said, one can code an application into interface hell, where everything has an interface and almost nothing needs an interface because there's only ever going to be one concrete implementation of the service. Happily, in .NET Core for example, the DI engine doesn't require interfaces - you can specify "this service is implemented by its concrete type" rather than always having to say "this service implements this interface." I have literally chucked out thousands of lines of interface code (I pity the programmer that wrote all that crap -- it wasn't me) because they were glommed onto the "DI must be done with interfaces" not realizing they were making pointless work for themselves because the never ever would have multiple concrete implementations for the interface abstraction. Know when to use an interface rather than always use an interface. Much like, um...
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a DomainMarc Clifton wrote:
Know when to use an interface rather than always use an interface. Much like, um...
Having an interface as an abstract class (in C++ - all functions are pure virtual) and deriving the implementation class(es) from it can aid your thinking in that everything that is exposed to the caller must be defined in the base class. I find that it is very useful as an implementation-hiding technique. My DLLs tend to have the following APIs:
IFoo* CreateFooInterface(<parameters>);
void DestroyFooInterface(IFoo*);(Calls to the methods of an IFoo object)
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
DI is overrated. Programming "to" an interface is fine when you have a real use case to abstract different implementations that you may want to switch between when service A (or controller A) needs to support service implementations S1, S2, and S3. For example, you might have several document store services, one for AWS buckets, one for your own document server, one for storing documents as blobs in a DB and different ones get instantiated on the fly depending on other factors. That said, one can code an application into interface hell, where everything has an interface and almost nothing needs an interface because there's only ever going to be one concrete implementation of the service. Happily, in .NET Core for example, the DI engine doesn't require interfaces - you can specify "this service is implemented by its concrete type" rather than always having to say "this service implements this interface." I have literally chucked out thousands of lines of interface code (I pity the programmer that wrote all that crap -- it wasn't me) because they were glommed onto the "DI must be done with interfaces" not realizing they were making pointless work for themselves because the never ever would have multiple concrete implementations for the interface abstraction. Know when to use an interface rather than always use an interface. Much like, um...
Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain
