Understanding IOC
-
I've recently read about the Inversion of Control (IOC) principle and I have a few questions I'd like to have answered. I've read that in order to implement the principle of IOC, one must not define a class and pass in concrete objects as its constructor's parameters but one must instead use interfaces as its constructor's parameters. My first question is can I implement IOC by defining a class with virtual classes as its constructor's parameters instead of interfaces. After all the whole reason behind using interfaces is to decouple the class from its dependencies and virtual classes can pretty much do that. My second question is can I use abstract classes as the parameters instead of interfaces. Thanks in advance for your reply.
-
I've recently read about the Inversion of Control (IOC) principle and I have a few questions I'd like to have answered. I've read that in order to implement the principle of IOC, one must not define a class and pass in concrete objects as its constructor's parameters but one must instead use interfaces as its constructor's parameters. My first question is can I implement IOC by defining a class with virtual classes as its constructor's parameters instead of interfaces. After all the whole reason behind using interfaces is to decouple the class from its dependencies and virtual classes can pretty much do that. My second question is can I use abstract classes as the parameters instead of interfaces. Thanks in advance for your reply.
C# doesn't support the concept of virtual classes so, in the context of this forum, the first part of your question makes no sense. With regards to using abstract classes, yes you can. Only a very poor IoC framework wouldn't support them but there are things to consider. First of all, we tend to prefer composition over inheritance nowadays, so an abstract base class would be a violation of that principal. Versioning an interface is difficult to do, so if you need to inject something that is version aware, you should consider using an abstract class in that case.
This space for rent
-
C# doesn't support the concept of virtual classes so, in the context of this forum, the first part of your question makes no sense. With regards to using abstract classes, yes you can. Only a very poor IoC framework wouldn't support them but there are things to consider. First of all, we tend to prefer composition over inheritance nowadays, so an abstract base class would be a violation of that principal. Versioning an interface is difficult to do, so if you need to inject something that is version aware, you should consider using an abstract class in that case.
This space for rent
-
Hi thanks for replying. I meant to say a generic class that has virtual methods or methods that take generic types T.
Again, you can pass in a generic class to most IoC containers. As soon as you introduce virtual methods, you are getting back to the argument about preferring composition over inheritance again.
This space for rent
-
I've recently read about the Inversion of Control (IOC) principle and I have a few questions I'd like to have answered. I've read that in order to implement the principle of IOC, one must not define a class and pass in concrete objects as its constructor's parameters but one must instead use interfaces as its constructor's parameters. My first question is can I implement IOC by defining a class with virtual classes as its constructor's parameters instead of interfaces. After all the whole reason behind using interfaces is to decouple the class from its dependencies and virtual classes can pretty much do that. My second question is can I use abstract classes as the parameters instead of interfaces. Thanks in advance for your reply.
I'd like to add to Pete's correct answer that your question actually deals with two concepts: the inversion of control on one hand, and abstraction on the other hand. The abstraction is the part where it comes to (abstract) base classes or better interfaces instead of concrete classes: you can use many other concrete implementations later on. The inversion of control principle is about the question of how to get a class one depends on. If A requires a B for some tasks, it is not the responsibility of A to create B, rather someone else should provide B for A (inject a B into A). While that can be done also with a concrete definition of B, a more abstract definition (see above) is preferred.
-
I've recently read about the Inversion of Control (IOC) principle and I have a few questions I'd like to have answered. I've read that in order to implement the principle of IOC, one must not define a class and pass in concrete objects as its constructor's parameters but one must instead use interfaces as its constructor's parameters. My first question is can I implement IOC by defining a class with virtual classes as its constructor's parameters instead of interfaces. After all the whole reason behind using interfaces is to decouple the class from its dependencies and virtual classes can pretty much do that. My second question is can I use abstract classes as the parameters instead of interfaces. Thanks in advance for your reply.
I don't believe IOC excludes "constructors with concrete objects"; it's simply another method of "dependency injection"; which is one of the functions of "IOC".
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
I've recently read about the Inversion of Control (IOC) principle and I have a few questions I'd like to have answered. I've read that in order to implement the principle of IOC, one must not define a class and pass in concrete objects as its constructor's parameters but one must instead use interfaces as its constructor's parameters. My first question is can I implement IOC by defining a class with virtual classes as its constructor's parameters instead of interfaces. After all the whole reason behind using interfaces is to decouple the class from its dependencies and virtual classes can pretty much do that. My second question is can I use abstract classes as the parameters instead of interfaces. Thanks in advance for your reply.
IOC does not preclude specifying concrete classes as parameter to be injected in the constructor, although some IOC container implementations my not support this. The IOC container is basically a super factory that can provide instances of classes or interfaces that have been registered with the IOC container or that the container can determine how to build. The Munq IOC Container, for example, can instantiate concrete classes even if they have not been registered, as long as all of the constructor parameters can be provided from the IOC Container. In most IOC Containers, you can register a class that, implements either an Interface or a Base Class, to be provided when either the Interface or Base Class is requested. This means your code now says "I need an instance of class X and I don't care or want to know how to build it, just give it to me" rather than "I need an instance of class X so I'll build up all itsdependencies, and their dependencies to do that. God help me if the dependency hierarchy changes".
"Time flies like an arrow. Fruit flies like a banana."