Have a hard time understanding it? Let me simplify it for you. If it is so hard for you to understand what and in means, don’t feel ashamed of it, you are not alone. Covariance Contravariance .NET C# It happened to me and many other developers. I even know experienced developers who either don’t know about them or are using them but still can’t understand them well enough. From where I see it, this is happening because every time I come across an article talking about and , I find it focused on some technical terminologies rather than being concerned about the reason why we have them in the first place and what we would have missed if they didn’t exist. Covariance Contravariance Microsoft’s Definition If you check for the and in , you would find this definition: Microsoft’s documentation Covariance Contravariance .NET C# In C#, covariance and contravariance enable implicit reference conversion for array types, delegate types, and generic type arguments. Covariance preserves assignment compatibility and contravariance reverses it. Do you get it? do you like it? You can search the internet and you will find tons of resources about this topic. You will come across definitions, history, when introduced, code samples… and many others and this is not what you would find in this article. I promise you that what you would see here is different…. What are they actually? Basically, what Microsoft did is that they added a small addition to the way you define your generic template type placeholder, the famous . <T> What you used to do when defining a generic interface is to follow the pattern . After having Covariance and Contravariance introduced, you can now follow the pattern or . public interface IMyInterface<T> {…} public interface IMyInterface<out T> {…} public interface IMyInterface<in T> {…} Do you recognize the extra and ? out in Have you seen them somewhere else? Maybe on the famous .NET ? Or the famous .NET ? public interface IEnumerable<out T> public interface IComparable<in T> Microsoft introduced a new concept so that the compiler -at design time- would make sure that the types of objects you use and pass around generic members would not throw runtime exceptions caused by wrong type expectations. Still not clear, right? Just bear with me... Let’s assume that the compiler doesn’t apply any design time restrictions and see what would happen. What if the compiler doesn’t apply any design time restrictions? To be able to work on an appropriate example, let’s define the following: public class A
{
	public void F1(){}
}

public class B : A
{
	public void F2(){}
}

public class C : B
{
	public void F3(){}
}

public interface IReaderWriter<TEntity>
{
	TEntity Read();
	void Write(TEntity entity);
}

public class ReaderWriter<TEntity> : IReaderWriter<TEntity> where TEntity : new()
{
	public TEntity Read()
	{
		return new TEntity();
	}

	public void Write(TEntity entity)
	{
	}
} Looking into the code above, you will notice that: Class A has defined. F1() Class B has and defined. F1() F2() Class C has , , and defined. F1() F2() F3() The interface has which returns an object of type and which expects a parameter of type . IReaderWriter Read() TEntity Write(TEntity entity) TEntity Then let’s define a method as follows: TestReadWriter() public static void TestReaderWriter(IReaderWriter param)
{
	var b = param.Read();
	b.F1();
	b.F2();

	param.Write(b);
} Calling when passing in an instance of TestReadWriter() IReaderWriter This should as we are not violating any rules. is already expecting a parameter of type . work fine TestReadWriter() IReaderWriter Calling when passing in an instance of TestReadWriter() IReaderWriter<A> , this means that: Keeping in mind the assumption that the compiler doesn’t apply any design time restrictions would return an instance of class , So, the would actually be of type , This would lead to the line to as the -which is actually of type - does not have defined param.Read() A not B=> var b A not B=> b.F2() fail var b A F2() line in the code above would be expecting to receive a parameter of type , not **B
\ => So, calling while passing in a parameter of type would both param.Write() A param.Write() B work fine Therefore, since in the point we are expecting a runtime failure, then we can’t call with passing in an instance of . #1 TestReadWriter() IReaderWriter<A> Calling when passing in an instance of TestReadWriter() IReaderWriter<C> , this means that: Keeping in mind the assumption that the compiler doesn’t apply any design time restrictions would return an instance of class , not So, the would actually be of type , not This would lead to the line to as the would have param.Read() C B=> var b C B=> b.F2() work fine var b F2() line in the code above would be expecting to receive a parameter of type , not **B
\ => So, calling while passing in a parameter of type would because simply you can’t replace with its parent param.Write() C param.Write() B fail C B Therefore, since in the point we are expecting a runtime failure, then we can’t call with passing in an instance of . #2 TestReadWriter() IReaderWriter<C> Now, let’s analyze what we have discovered up to this moment: Calling when passing in an instance of is always fine. TestReadWriter(IReaderWriter param) IReaderWriter Calling when passing in an instance of would be fine if we don’t have the call. TestReadWriter(IReaderWriter param) IReaderWriter<A> param.Read() Calling when passing in an instance of would be fine if we don’t have the call. TestReadWriter(IReaderWriter param) IReaderWriter<C> param.Write() However, since we always have a mix between and , we would always have to stick to calling with passing in an instance of , nothing else. param.Read() param.Write() TestReadWriter(IReaderWriter param) IReaderWriter Unless……. The Alternative What if we make sure that the interface defines either or , not both of them at the same time. IReaderWriter<TEntity> TEntity Read() void Write(TEntity entity) Therefore, if we drop the , we would be able to call with passing in an instance of or . TEntity Read() TestReadWriter(IReaderWriter param) IReaderWriter<A> IReaderWriter Similarly, if we drop the , we would be able to call with passing in an instance of or . void Write(TEntity entity) TestReadWriter(IReaderWriter param) IReaderWriter IReaderWriter<C> This would be better for us as it would be less restrictive, right? Time for some Facts In the real world, the compiler -in design time- would never allow calling with passing in an instance of . You would get a compilation error. TestReadWriter(IReaderWriter param) IReaderWriter<A> Also, the compiler -in design time- would not allow calling with passing in an instance of . You would get a compilation error. TestReadWriter(IReaderWriter param) IReaderWriter<C> From point #1 and #2, this is called . Invariance Even if you drop the from the interface, the compiler -in design time- would not allow you to call with passing in an instance of . You would get a compilation error. This is because the compiler would not -implicitly by itself- look into the members defined into the interface and see if it is going to always work at runtime or not. You will need to do this by yourself through . This acts as a promise from you to the compiler that all members in the interface would either don’t depend on or deal with it as an , . This is called . TEntity Read() IReaderWriter<TEntity> TestReadWriter(IReaderWriter param) IReaderWriter<A> <in TEntity> TEntity input not an output Contravariance Similarly, even if you drop the from the interface, the compiler -in design time- would not allow you to call with passing in an instance of . You would get a compilation error. This is because the compiler would not -implicitly by itself- look into the members defined into the interface and see if it is going to always work at runtime or not. You will need to do this by yourself through . This acts as a promise from you to the compiler that all members in the interface would either don’t depend on or deal with it as an , . This is called . void Write(TEntity entity) IReaderWriter<TEntity> TestReadWriter(IReaderWriter param) IReaderWriter<C> <out TEntity> TEntity output not an input Covariance Therefore, adding or makes the compiler less restrictive to serve our needs, not more restrictive as some developers would think. <out > <in > Summary At this point, you should already understand the full story of , and . Invariance Covariance Contravariance However, as a quick recap, you can deal with the following as a : cheat sheet Mix between input and output generic type => Invariance => the most restrictive => can’t replace with parents or children. Added => only => => . <in > input Contravariance itself or replace with parents Added => only => => . <out > output Covariance itself or replace with children Finally, I will drop here some code for you to check. It would help you practice more. using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace DotNetVariance
{
	class Program
	{
		static void Main(string[] args)
		{
			IReader<A> readerA = new Reader<A>();
			IReader readerB = new Reader();
			IReader<C> readerC = new Reader<C>();
			IWriter<A> writerA = new Writer<A>();
			IWriter writerB = new Writer();
			IWriter<C> writerC = new Writer<C>();
			IReaderWriter<A> readerWriterA = new ReaderWriter<A>();
			IReaderWriter readerWriterB = new ReaderWriter();
			IReaderWriter<C> readerWriterC = new ReaderWriter<C>();

			#region Covariance
			// IReader<TEntity> is Covariant, this means that:
			// 1. All members either don't deal with TEntity or have it in the return type, not the input parameters
			// 2. In a call, IReader<TEntity> could be replaced by any IReader<TAnotherEntity> given that TAnotherEntity
			// is a child -directly or indirectly- of TEntity

			// TestReader(readerB) is ok because TestReader is already expecting IReader
			TestReader(readerB);

			// TestReader(readerC) is ok because C is a child of B
			TestReader(readerC);

			// TestReader(readerA) is NOT ok because A is a not a child of B
			TestReader(readerA);
			#endregion

			#region Contravariance
			// IWriter<TEntity> is Contravariant, this means that:
			// 1. All members either don't deal with TEntity or have it in the input parameters, not in the return type
			// 2. In a call, IWriter<TEntity> could be replaced by any IWriter<TAnotherEntity> given that TAnotherEntity
			// is a parent -directly or indirectly- of TEntity

			// TestWriter(writerB) is ok because TestWriter is already expecting IWriter
			TestWriter(writerB);

			// TestWriter(writerA) is ok because A is a parent of B
			TestWriter(writerA);

			// TestWriter(writerC) is NOT ok because C is a not a parent of B
			TestWriter(writerC);
			#endregion

			#region Invariance
			// IReaderWriter<TEntity> is Invariant, this means that:
			// 1. Some members have TEntity in the input parameters and others have TEntity in the return type
			// 2. In a call, IReaderWriter<TEntity> could not be replaced by any IReaderWriter<TAnotherEntity>

			// IReaderWriter(readerWriterB) is ok because TestReaderWriter is already expecting IReaderWriter
			TestReaderWriter(readerWriterB);

			// IReaderWriter(readerWriterA) is NOT ok because IReaderWriter can not be replaced by IReaderWriter<A>
			TestReaderWriter(readerWriterA);

			// IReaderWriter(readerWriterC) is NOT ok because IReaderWriter can not be replaced by IReaderWriter<C>
			TestReaderWriter(readerWriterC);
			#endregion
		}

		public static void TestReader(IReader param)
		{
			var b = param.Read();
			b.F1();
			b.F2();

			// What if the compiler allows calling TestReader with a param of type IReader<A>, This means that:
			// param.Read() would return an instance of class A, not B
			//		=> So, the var b would actually be of type A, not B
			//		=> This would lead to the b.F2() line in the code above to fail as the var b doesn't have F2()

			// What if the compiler allows calling TestReader with a param of type IReader<C>, This means that:
			// param.Read() would return an instance of class C, not B
			//		=> So, the var b would actually be of type C, not B
			//		=> This would lead to the b.F2() line in the code above to work fine as the var b would have F2()
		}

		public static void TestWriter(IWriter param)
		{
			var b = new B();
			param.Write(b);

			// What if the compiler allows calling TestWriter with a param of type IWriter<A>, This means that:
			// param.Write() line in the code above would be expecting to receive a parameter of type A, not B
			//		=> So, calling param.Write() while passing in a parameter of type A or B would both work

			// What if the compiler allows calling TestWriter with a param of type IWriter<C>, This means that:
			// param.Write() line in the code above would be expecting to receive a parameter of type C, not B
			//		=> So, calling param.Write() while passing in a parameter of type B would not work
		}

		public static void TestReaderWriter(IReaderWriter param)
		{
			var b = param.Read();
			b.F1();
			b.F2();

			param.Write(b);

			// What if the compiler allows calling TestReaderWriter with a param of type IReaderWriter<A>, This means that:
			// 1. param.Read() would return an instance of class A, not B
			//		=> So, the var b would actually be of type A, not B
			//		=> This would lead to the b.F2() line in the code above to fail as the var b doesn't have F2()
			// 2. param.Write() line in the code above would be expecting to receive a parameter of type A, not B
			//		=> So, calling param.Write() while passing in a parameter of type A or B would both work

			// What if the compiler allows calling TestReaderWriter with a param of type IReaderWriter<C>, This means that:
			// 1. param.Read() would return an instance of class C, not B
			//		=> So, the var b would actually be of type C, not B
			//		=> This would lead to the b.F2() line in the code above to work fine as the var b would have F2()
			// 2. param.Write() line in the code above would be expecting to receive a parameter of type C, not B
			//		=> So, calling param.Write() while passing in a parameter of type B would not work
		}
	}

	#region Hierarchy Classes
	public class A
	{
		public void F1()
		{
		}
	}

	public class B : A
	{
		public void F2()
		{
		}
	}

	public class C : B
	{
		public void F3()
		{
		}
	}
	#endregion

	#region Covariant IReader
	// IReader<TEntity> is Covariant as all members either don't deal with TEntity or have it in the return type
	// not the input parameters
	public interface IReader<out TEntity>
	{
		TEntity Read();
	}

	public class Reader<TEntity> : IReader<TEntity> where TEntity : new()
	{
		public TEntity Read()
		{
			return new TEntity();
		}
	}
	#endregion

	#region Contravariant IWriter
	// IWriter<TEntity> is Contravariant as all members either don't deal with TEntity or have it in the input parameters
	// not the return type
	public interface IWriter<in TEntity>
	{
		void Write(TEntity entity);
	}

	public class Writer<TEntity> : IWriter<TEntity> where TEntity : new()
	{
		public void Write(TEntity entity)
		{
		}
	}
	#endregion

	#region Invariant IReaderWriter
	// IReaderWriter<TEntity> is Invariant as some members have TEntity in the input parameters
	// and others have TEntity in the return type
	public interface IReaderWriter<TEntity>
	{
		TEntity Read();
		void Write(TEntity entity);
	}

	public class ReaderWriter<TEntity> : IReaderWriter<TEntity> where TEntity : new()
	{
		public TEntity Read()
		{
			return new TEntity();
		}

		public void Write(TEntity entity)
		{
		}
	}
	#endregion
} That’s it, hope you found reading this article as interesting as I found writing it. Also published here.

Check my links 😀

My HackerNoon Stories

My Medium Articles

Buy Me a Coffee

Buy Me a Gift

Check My Links

Hire Me

Too Long; Didn't Read

Making security fun one episode at a time

The Difference Between Covariance and Contravariance in .NET C#

Too Long; Didn't Read

Ahmed Tarek Hasan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

The Difference Between Covariance and Contravariance in .NET C#

Too Long; Didn't Read

Ahmed Tarek Hasan

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES