Click here to Skip to main content
15,907,392 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
Hi all,

I noticed this code in an example on the Unity framework.

IUnityContainer container = new UnityContainer();


I have never seen a reference to an interface before. Why is this done instead of having the following?

UnitContainer container = new UnitContainer();


I would appreciate some insight on why an interface is used like this. What are the advantages here? Thanks guys.
Posted
Updated 11-Oct-11 11:47am
v2
Comments
Sergey Alexandrovich Kryukov 11-Oct-11 17:54pm    
Just think of your second line: what would be the use of the knowledge that container is UnitContainer?
--SA
Isaiah83 11-Oct-11 17:57pm    
The object can be passed to any method that requires an IUnity Object to be passed to it? Would that be it?
Sergey Alexandrovich Kryukov 11-Oct-11 18:24pm    
I don't understand this second question. I explained this line in my solution.
If you said "the object container can be passed to any method that required an instance of IUnityContainer as a parameter", it would be true, but not all what's involved. Passing a parameter is only one special case of assignment compatibility: a variable of some type could be assigned a value of more derived type. Do I have to explain why? Think about the fact that a more derived class extends its base class, not the other way around.
--SA

What you see is the very heart of interfaces and almost the very heart of OOP (the real hart of which is late binding using virtual). Understanding such things is one of prerequisites to understanding of the very basics of OOP.

For a minute, forget that IUnityContainer is interface, let's just talk in terms of some types which allow inheritance. Is there anything unusual to you?
The type in declaration IUnityContainer on left is a compile-time type; the type of constructor on right defines run-time type class. Do you know why we need different compile-time and run-time classes? Ever heard of abstraction? Hiding of excessive detail? Even though we ignore the fact one of those types is interface, we can consider a compile-time type as an abstract interface to a set of different possible concrete classes. When as work with the variable container, we don't need anything that makes different concrete classes different, we want to work with abstract interface. The type UnityContainer is derived from the type IUnityContainer; it makes the variable container assignable to the value on the right of "=".

I was talking only about types above, not mentioning classes or interfaces. We only needed to idea of inheritance. Additionally, in classes, the modification of behavior of the concrete classes is supported by virtual methods (and properties) and late binding.

Now, adding the notion of interface to the picture. In our context, consider using interface as an additional constraint to our compile-time type. A base class could be non-abstract and could be instantiated, but interface is always abstract. A base class could have data, but interface cannot. The idea is that concrete implementation is only defined at the moment of construction, and all the usage of objects is done via interface references only.

Interfaces can one more distinct feature related to polymorphism. The mechanism of virtual methods is only applicable to classes, which are reference type. Is the polymorphism possible with value types? Yes, but this fact is not very well known by many developers. The thing is: interfaces could be implemented even by structures (struct). So, the polymorphism using interfaces for abstract types can go so far that it can be agnostic not only about concrete implementing types, but even about the knowledge what types are the reference types and what are the value types.

Also, multiple inheritance is possible with interfaces but not classes. More exactly, an interface can have unlimited number of base interfaces; and a class can have only one base class but unlimited number of base interfaces in inheritance list. This is called weak form of multiple inheritance.

I would say, it you have problem understanding of anything from what I mentioned above, you will need to start learning OOP from the very beginning. It's very useful anyway; if you do it well, the time and effort will pay off pretty soon.

—SA
 
Share this answer
 
v5
Comments
Isaiah83 12-Oct-11 10:47am    
Thank you for your effort in your response. I do understand most of what you talked about, especially with multiple inheritance in interfaces - it just enforces a longer running contract between classes.

Can you come up with an example that demonstrates how assigning a variable of an interface to a concrete class constructor is valuable?
IUnityContainer container = new UnityContainer();
I read this code as: create a new instance of the UnityContainer object: that object implements IUnityContainer. By definition, you cannot create an instance of an interface. So, in this case, you are not "initializing an object from an interface."
UnitContainer container = new UnitContainer();
To understand how this invocation differs from the first, I'd need to know: what are the differences between UnityContainer and UnitContainer ? I'd speculate that UnitContainer does not implement IUnityContainer.
 
Share this answer
 
v2
Comments
Isaiah83 12-Oct-11 10:01am    
Thanks for your response. I did notice I typed "Unit" and not Unity for the second line of code. UnityContainer does implement IUnityContainer, and that's why I am wondering why choose to reference IUnityContainer versus just having a reference to UnityConainer.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900