DEV Community: Ahmed Tarek Hasan

🚀 Official Launch of DSP Community 🎉

Ahmed Tarek Hasan — Tue, 09 Jan 2024 15:54:40 +0000

I am thrilled to share with you the official launch of my new software engineering website, blog, and community.

Development Simply Put, your ultimate destination for software engineering excellence. Explore insightful blog posts and articles covering industry trends. Engage in interactive quizzes to test your knowledge, and master the craft with comprehensive tutorials. Elevate your skills with expert tips, tricks, hints, and best practices. Dive into design patterns to create robust solutions. Join our vibrant community and stay ahead in the dynamic world of software engineering.

developmentsimplyput.com

A space that goes beyond a traditional blog to become a thriving software engineering community!

After a lot of hard work and dedication, I’ve finally launched my website and blog to provide you with the latest insights, tips, and resources in the world of software engineering. I’ve also taken the time to republish my previous articles on the new blog.

Software blog with articles and posts about all aspects of Software Engineering, Architecture, Development, Programming, and Coding. Here you can find best practices, explanations, tutorials, guides, tips, hints, code samples, and more.

developmentsimplyput.com

However, please keep in mind, this project has been a labor of love, and I’m excited to turn it into more than just a blog. My vision is to cultivate a thriving community where collaboration and innovation take center stage.

🌟 What Inspired Me

Years ago, Albert Einstein’s timeless words became my guiding principle:

If you can’t explain it simply, you don’t understand it well enough.

This simple yet profound statement sparked my journey into blogging and writing technical content, fulfilling my passion for learning and sharing knowledge which eventually helps me learn more.

However, as the days passed, I yearned for more. It dawned on me — what about the other dimensions of my life as a software engineer? How do I socialize, generate new ideas, present myself better? After that realization, it was so obvious what to call my initiative; “Development Simply Put”. Contrary to common perception — even among those close to me — it was never about Software Engineering Development; it was always about Software Engineers Development.

👥 Join the Community

Discover a space that goes beyond traditional blogging. The website aims to foster connections, discussions, and collaborations within the dynamic world of software engineering.

🌟 What’s in Store

I have big plans for the future, including engaging activities, collaborative projects, and opportunities for community members to shine. Stay tuned for exciting developments!

Development Simply Put DSP Community Blog Posts Articles Tips Hints Tricks Tutorials Quizzes Evaluations Projects .NET DotNet C# CSharp Code Coding Programming Software Design Development Engineering Architecture Best Practice Ahmed Tarek

📬 Subscribe to Stay Connected

Be part of this journey from the start by subscribing to my newsletter. Get the latest updates directly in your inbox and be the first to know about upcoming community initiatives.

Subscribe to Development Simply Put to get articles and posts about all aspects of Software Engineering, Architecture, Development, Programming, and Coding. You would get best practices, explanations, tutorials, guides, tips, hints, code samples, and more.

developmentsimplyput.com

💡 How You Can Support

1️⃣ Subscribe: Receive great content and be a part of the community from day one.
2️⃣ Engage: Read, rate, and comment on blog articles to fuel discussions.
3️⃣ Share: Spread the knowledge by sharing articles on social media.
4️⃣ Spread the Word: Help grow our community by sharing this announcement.
5️⃣ Other ways…

🗣 Your Voice Matters

Your support is crucial in making this vision a reality, and I can’t wait to build a vibrant community together. I invite you to share your thoughts, suggestions, and topics you’d like to see covered. Let’s build this community together!

Thank you for being a part of this exciting journey! 🚀

🎁Presents
Don’t forget to check our Free Udemy Coupons Page.

LinkedIn group which shares free coupons for Udemy courses on different fields of knowledge. The main goal of this initiative is to encourage people to persist a daily habit of learning new skills rather than doing it occasionally.

developmentsimplyput.com

Also, out partner DSP Stylish Designs.

A new brand providing unique apparel (t-shirts, hoodie, tank, crewneck,…) and other print on demand products (bottles, magnets, mouse pads,…) specifically catered to software engineering enthusiasts.

Their slogan is “𝐶𝑟𝑎𝑓𝑡𝑖𝑛𝑔 𝐸𝑙𝑒𝑔𝑎𝑛𝑐𝑒, 𝑂𝑛𝑒 𝑃𝑟𝑖𝑛𝑡 𝑎𝑡 𝑎 𝑇𝑖𝑚𝑒”.

A new brand providing unique apparel (t-shirts, hoodie, tank, crewneck,...) and other print on demand products (bottles, magnets, mouse pads,...) specifically catered to software engineers, developers, programmers, coders,... Our slogan is; Crafting Elegance, One Print at a Time.

developmentsimplyput.com

Finally, hope you like what Development Simply Put community is offering and wish to meet you there 😃

How to Use Observables with Vanilla JavaScript

Ahmed Tarek Hasan — Fri, 31 Dec 2021 09:36:37 +0000

No frameworks used, just pure vanilla JavaScript.

While working on a side project just for fun, I wanted to write a JavaScript script to call a REST API and eventually do some cool stuff on a webpage. It is purely vanilla JavaScript, with no fancy frameworks or even libraries being used.

First, I thought of using Promises for my calls and this was easy for me. I have done that a ton of times. However, it then hit me hard — why don’t I use Observables? I knew that vanilla JavaScript didn’t natively support Observables. But couldn’t I implement it myself? And that’s what I did.

This is how I thought things through

The Observable itself would be of a new object type called Subject.
This Subject object should expose the subscribe and next functions.
subscribe should be called by observers to subscribe to the observable stream of data.
next should be called by the Subject owner to push/publish new data whenever available.
Additionally, I wanted the Subject owner to be able to know whenever no observers were interested in its data. This would enable the Subject owner to decide if he still wanted to get the data or not.
Also, the Subject owner should be able to know whenever at least one observer started being interested in its data. This would give the Subject owner more control on its data flow and any related operations.
Now back to the observer. He should be able to unsubscribe from the Subject at any time.
This leads us to a new object type called Subscription.
This Subscription object should expose an unsubscribe function.
unsubscribe should be called by the observer whenever he wants to stop listening to the data stream coming from the Subject.

Following these rules, I came up with the following implementation.

Implementation

Subscription

let Subscription = function(handlerId, unsubscribeNotificationCallback) {
    let self = this;

    self.unsubscribe = () => {
        if(unsubscribeNotificationCallback) {
            unsubscribeNotificationCallback(handlerId);
        }
    };

    return self;
};

Note that Subscription just notifies the Subject when the unsubscribe function is called.

Subject

let Subject = function(subscribersStateChangeNotificationCallback) {
    let self = this;

    let handlers = {};

    Object.defineProperty(self, "subscribersFound", {
        get() {
            let found = false;

            for(const prop in handlers) {
                if(handlers.hasOwnProperty(prop)) {
                    found = true;
                    break;
                }
            }

            return found;
        }
    });

    Object.defineProperty(self, "subscribersCount", {
        get() {
            let count = 0;

            for(const prop in handlers) {
                if(handlers.hasOwnProperty(prop)) {
                    count++;
                }
            }

            return count;
        }
    });

    let unsubscribeNotificationCallback = (handlerId) => {
        if(handlerId && handlerId !== '' && handlers.hasOwnProperty(handlerId)) {
            delete handlers[handlerId];

            if(subscribersStateChangeNotificationCallback && !self.subscribersFound) {
                subscribersStateChangeNotificationCallback(false);
            }
        }
    };

    self.subscribe = (handler) => {
        let handlerId = createGuid();
        handlers[handlerId] = handler;

        if(subscribersStateChangeNotificationCallback && self.subscribersCount === 1) {
            subscribersStateChangeNotificationCallback(true);
        }

        return new Subscription(handlerId, unsubscribeNotificationCallback);
    };

    self.next = (data) => {
        for(const handlerId in handlers) {
            handlers[handlerId](data);
        }
    };

    return self;
};

let createGuid = function() {  
   return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {  
      var r = Math.random()*16|0, v = c === 'x' ? r : (r&0x3|0x8);  
      return v.toString(16);  
   });  
};

Somewhere in the Subject Owner

.
.
.
let subscribersStateChangeNotificationCallback = (subscriberFound) => {
    if(!subscriberFound && isNowWatching) {
        stopWatching();
        isNowWatching = false;
    } else if(subscriberFound && !isNowWatching) {
        startWatching();
    }
};

self.data = new Subject(subscribersStateChangeNotificationCallback);
.
.
.
self.data.next(self.snapshot.data);
.
.
.

Somewhere in the Observer

.
.
.
const dashboardServiceSubscription = myDashboardService.data.subscribe((data) => {
    ...
});
.
.
.
dashboardServiceSubscription.unsubscribe();
.
.
.

That’s it, everything worked like a charm and I was proud of what I achieved.

So, the punch line is that coding in vanilla JavaScript is not always equal to writing boring code, you can make it much more fun 😃

Hope you found reading this story as interesting as I found writing it.

This article was originally published here.

A Best Practice for Designing Interfaces in .NET C#

Ahmed Tarek Hasan — Wed, 29 Dec 2021 10:32:12 +0000

Is it enough to define `IMyInterface<T>`? do I need `IMyInterface` as well?

While working on your masterpiece software system, you define your own interfaces to act as contracts between your different system modules and to expose some contracts to the outside world. This is not rocket science to any software developer.

However, what I learned throughout my years as a Software Engineer is that we should put more care about how we design our interfaces. If you search the internet, you would find tons of resources discussing the best practices to follow when designing interfaces, some of these are actually good resources.

But, I have one more best practice to tell you about which I couldn’t find online except for rare coincidences.

Is it enough to define `IMyInterface<T>`? do I need `IMyInterface` as well?

To answer this question, let’s walk through the example below step by step, so bear with me and don’t rush things out.

Disclaimer

We would not follow a lot of the best practices here for simplicity and to drive the main focus to the topic we are discussing. So, no unnecessary abstractions, no care for immutability,….and so on.

Main Entity Classes

These are the main entity classes we are going to use.

// This class is representing the simple entity we are going to use
// in our example. 
public class Data
{
    public int DataId { get; set; }
    public string DataDescription { get; set; }
}

// This class is the first kind of the parent Data class.
public class EmployeeData : Data
{
    public string EmployeeName { get; set; }
}

// This class is the second kind of the parent Data class.
public class AssetData : Data
{
    public int AssetId { get; set; }
    public string AssetName { get; set; }
}

Generic Interface

This is the generic interface we are going to use and we should focus on.

// This is the interface we are going to focus on.
// It is an interface for something that would be able
// to read and write data to something that is ready
// to be used this way.
public interface IReaderWriter<TData> where TData : Data
{
    void Initialize();
    TData Read(int dataId);
    void Write(TData data);
}

We notice on this interface the following:

It is a generic interface which accepts a generic parameter of type Data.
It has an Initialize method.
It has a Read(int dataId) method which expects an integer parameter and returns a TData.
It has Write(TData data) method which expects a TData parameter.

Generic Interface Implementer

This is the class implementing our generic interface. The class itself is generic.

// This is the class implementing our IReaderWriter<TData>
// but now we know that it is going to save and retrieve
// data to and from a file. We would not care about the
// implementation so don't give it too much thought.
public class FileReaderWriter<TData> : IReaderWriter<TData> where TData : Data
{
    public void Initialize() { throw new NotImplementedException(); }

    public TData Read(int dataId) { throw new NotImplementedException(); }

    public void Write(TData data) { throw new NotImplementedException(); }
}

We notice on this class the following:

It is a generic class.
The methods are throwing exceptions and this is intentionally done to drive the main focus to where it belongs.

Inside the Employee Module

Now, in your system, you have a module dedicated to managing Employee data, let’s call this module; Employee Module.

Inside the Employee Module, you are sure of the type of the data you are dealing with, it is obviously of type EmployeeData.

That’s why you can write code like the one below without having any problems.

var employeeDataFileReaderWriter = new FileReaderWriter<EmployeeData>();
employeeDataFileReaderWriter.Initialize();

employeeDataFileReaderWriter.Write(new EmployeeData
    { DataId = 1, DataDescription = "Some description.", EmployeeName = "Ahmed" });

var ahmed = employeeDataFileReaderWriter.Read(1);

Inside the Asset Module

Now, in your system, you have a module dedicated to managing Asset data, let’s call this module; Asset Module.

Inside the Asset Module, you are sure of the type of the data you are dealing with, it is obviously of type AssetData.

That’s why you can write code like the one below without having any problems.

var assetDataFileReaderWriter = new FileReaderWriter<AssetData>();
assetDataFileReaderWriter.Initialize();

assetDataFileReaderWriter.Write(new AssetData
{ DataId = 2, DataDescription = "Some description.", AssetId = 5, AssetName = "Asset 5."});

var asset5 = assetDataFileReaderWriter.Read(2);

What About a Common Module

Now let’s assume that you have a common module that has a Run(IReaderWriter readerWriter) method. Inside this method you want to call the Initialize method of the passed in readerWriter parameter.

You would try to write something like this:

It is clear now that you can’t do it as you don’t have a non-generic definition of the IReaderWriter interface. In other words, we only have IReaderWriter<TData>, not IReaderWriter.

Wrong Expectations

Now, I can hear someone shouting from a far distance saying:

Huh, it is a piece of cake. Let’s use IReaderWriter<object>. Every class is a child of Object, right?….. genius.

My answer to him is that he should do his homework as this is not going to work. If either you or him don’t trust me on this, just give it a try and you would see the following:

You need more explanation right, the short answer is because your interface is Invariant; you can’t call a method expecting IReaderWriter<SomeClass> and pass in an instance of IReaderWriter<AnyOtherClass>. The only acceptable call would be with passing IReaderWriter<SomeClass>, nothing else.

If you want to understand more you can check my story Covariance and Contravariance in .NET C#. Have hard time understanding it? Let me simplify it for you.

This Is the Way

Now you understand why we need to define a non-generic IReaderWriter interface.

Therefore, moving on to the implementation, we can end up with this code:

public interface IReaderWriter
{
    void Initialize();
}

public interface IReaderWriter<TData> : IReaderWriter where TData : Data
{
    TData Read(int dataId);
    void Write(TData data);
}

Now, we can notice the following:

We defined a new interface but this time it is a non-generic interface.
This interface would define only the Initialize() method as this is what we actually need in the common module or even the new ones if they come in the future.
Now the other generic interface can safely extend the non-generic one with the Read and Write methods without changing anything on the signature.

Let’s Give It a Test Drive

So, now let’s go back to our common module and see if it is going to work or not.

Finally, it is working. Let’s celebrate and get something to eat and drink, what a trip 🙂

I don’t want to be a bearer of bad news here, but, I have bad news…

Why So Sad

You have new requirements coming in and the common module needs some modifications. The common module now should be able to store and retrieve data in and from a Blob storage. The Blob storage can store any kind of data.

So, based on this input, you would try to do something like this:

It is clear now that it is not going to work as IReaderWriter interface doesn’t define the Read and Write methods. They are defined in the IReaderWriter<TData>. However, on the common module and at the moment of calling StoreInBlob and RetrieveFromBlob methods, we don’t know the type of data. So, what to do!!!

The Wrong Way To Go

You might now lose hope and sadly decide to drop the whole generic interface thing. You would change the code to the following:

public interface IReaderWriter
{
    void Initialize();
    Data Read(int dataId);
    void Write(Data data);
}

public class FileReaderWriter : IReaderWriter
{
    public void Initialize() { throw new NotImplementedException(); }

    public Data Read(int dataId) { throw new NotImplementedException(); }

    public void Write(Data data) { throw new NotImplementedException(); }
}

So, now the common module would be fine as follows:

However, you lost the edge of dealing with strong-typed objects as follows:

Now you have to cast your Employee object so that you can access its unique members, like EmployeeName as in the image.

Similarly, you have to cast your **Asset **object so that you can access its unique members, like AssetName as in the image.

So, now what????

Moment of Truth

The keyword for the best solution here is the word new. Let me break it down for you.

public interface IReaderWriter
{
    void Initialize();
    Data Read(int dataId);
    void Write(Data data);
}

public interface IReaderWriter<TData> : IReaderWriter where TData : Data
{
    new TData Read(int dataId);
}

We can notice the following:

The IReaderWriter interface now defines are the required methods.
However, for the Read and Write methods, they are now using the parent Data entity type.
The IReaderWriter<TData> interface now extends the IReaderWriter interface.
This means that it also indirectly defines the three methods we know about.
However, inside the IReaderWriter<TData> interface, we need to use the generic type TData, not the parent Data.
To do so, we need to add TData Read(int dataId); and void Write(TData data); methods to the IReaderWriter<TData> interface.
For the read method, you can’t do this because the parent interface, the non-generic one, already defines the same exact method in terms of name and input parameters, but only different return type.
This would confuse the compiler at run time as it would not know which method to call, the one returning Data or the other one returning TData.
That’s why the compiler would not allow you to do so unless you add the new keyword at the start of the method definition as in the code above.
This instructs the compiler to hide the Read method inherited from the parent and replace it with the one defined after the new keyword.
Now, you might ask, why didn’t we do the same with the Write method?
The answer is simply because we don’t need to do so. In the parent interface, we already have a method called Write which expects a parameter of type Data which is the parent of all types that could be passed in to the Write method.
This means that this method could be called passing any TData could come.
Another thing, if you try to use the new keyword with the Write method, you would get a warning that you are actually not hiding anything from the parent interface. This is logical as the two Write methods have different input parameter types, so, it is sound and clear to the compiler that they are two different methods.

public class FileReaderWriter<TData> : IReaderWriter<TData> where TData : Data
{
    public void Initialize() { throw new NotImplementedException(); }

    public TData Read(int dataId) { throw new NotImplementedException(); }

    public void Write(TData data) { throw new NotImplementedException(); }

    Data IReaderWriter.Read(int dataId) { return Read(dataId); }

    void IReaderWriter.Write(Data data) { Write((TData)data); }
}

We can notice the following:

The old three methods are the same.
Now we have two more methods implemented.
The first method is Data IReaderWriter.Read(int dataId) { return Read(dataId); }.
This method is an explicit implementation of the Data Read(int dataId); method defined in the parent IReaderWriter interface.
This means that whenever an object of the FileReaderWriter<TData> class is casted, implicitly or explicitly, as the non-generic interface IReaderWriter, this Read method implementation would be used.
The second method is void IReaderWriter.Write(Data data) { Write((TData)data); }.
This method is an explicit implementation of the void Write(Data data); method defined in the parent IReaderWriter interface.
This means that whenever an object of the FileReaderWriter<TData> class is casted, implicitly or explicitly, as the non-generic interface IReaderWriter, this Write method implementation would be used.

This now leads to the following:

And

Finally, everything is working as it should 🙂

It Is What It Is

This design technique -afraid of even calling it a pattern- is already used in .NET classes you are using daily. Did you notice that in .NET we have IEnumerable and IEnumerable<T>? Could you imagine if we don’t have IEnumerable what would life be 🙂

This would mean that you can’t write code which loops on an enumerable, just an enumerable. You would always need to know first the type of items inside the enumerable.

You can argue that you still can write a method which accepts <T> and then it would pass it to the IEnumerable<T>, but my friend, this would keep bubbling up till you eventually would have to choose an entity type. This entity type is not always defined on all layers or levels of code as we proved above.

Therefore, my final advice to you, don’t try to beat around the bushes, it is what it is…

That’s it, hope you found reading this story as interesting as I found writing it.

This article was originally published here.

Resources

These are resources you might find useful.
Covariance and Contravariance in .NET C#

Covariance and Contravariance in .NET C#

Ahmed Tarek Hasan — Mon, 27 Dec 2021 22:08:34 +0000

Have hard time understanding it? Let me simplify it for you.

If it is so hard on you to understand what Covariance and Contravariance in .NET C# means, don’t feel ashamed of it, you are not alone.

It happened to me and many other developers. I even know experienced developers who either don’t know about them and 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 Covariance and Contravariance, 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.

Microsoft’s Definition

If you check Microsoft’s documentation for the Covariance and Contravariance in .NET C#, you would find this definition:

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 story. 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 place holder, the famous .

What you used to do when defining a generic interface is to follow the pattern public interface IMyInterface<T> {…}. After having Covariance and Contravariance introduced, you can now follow the pattern public interface IMyInterface<out T> {…} or public interface IMyInterface<in T> {…}.

Do you recognize the extra out and in?
Have you seen them somewhere else?
May be on the famous .NET public interface IEnumerable<out T>?
or the famous .NET 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 F1() defined.
Class B has F1() and F2() defined.
Class C has F1(), F2() , and F3() defined.
The interface IReaderWriter has Read() which returns an object of type TEntity and Write(TEntity entity) which expects a parameter of type TEntity.

Then let’s define a TestReadWriter() method as follows:

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

    param.Write(b);
}

Calling TestReadWriter() when passing in an instance of IReaderWriter

This should work fine as we are not violating any rules. TestReadWriter() is already expecting a parameter of type IReaderWriter.

Calling `TestReadWriter()` when passing in an instance of `IReaderWriter<A>`

Keeping in mind the assumption that the compiler doesn’t apply any design time restrictions, 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 to fail as the var b -which is actually of type A- does not have F2() defined
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 B would both work fine

Therefore, since in the point #1 we are expecting a runtime failure, then we can’t call TestReadWriter() with passing in an instance of IReaderWriter<A>.

Calling `TestReadWriter()` when passing in an instance of `IReaderWriter<C>`

Keeping in mind the assumption that the compiler doesn’t apply any design time restrictions, 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 to work fine as the var b would have F2()
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 fail because simply you can’t replace C with its parent B

Therefore, since in the point #2 we are expecting a runtime failure, then we can’t call TestReadWriter() with passing in an instance of IReaderWriter<C>.

Now, let’s analyze what we have discovered up to this moment:

Calling TestReadWriter(IReaderWriter param) when passing in an instance of IReaderWriter is always fine.
Calling TestReadWriter(IReaderWriter param) when passing in an instance of IReaderWriter<A> would be fine if we don’t have the param.Read() call.
Calling TestReadWriter(IReaderWriter param) when passing in an instance of IReaderWriter<C> would be fine if we don’t have the param.Write() call.
However, since we always have a mix between param.Read() and param.Write(), we would always have to stick to calling TestReadWriter(IReaderWriter param) with passing in an instance of IReaderWriter, nothing else.
Unless…….

The Alternative

What if we make sure that the IReaderWriter<TEntity> interface defines either TEntity Read() or void Write(TEntity entity), not both of them at the same time.

Therefore, if we drop the TEntity Read(), we would be able to call TestReadWriter(IReaderWriter param) with passing in an instance of IReaderWriter<A> or IReaderWriter.

Similarly, if we drop the void Write(TEntity entity), we would be able to call TestReadWriter(IReaderWriter param) with passing in an instance of IReaderWriter or 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 TestReadWriter(IReaderWriter param) with passing in an instance of IReaderWriter<A>. You would get a compilation error.
Also, the compiler -in design time- would not allow calling TestReadWriter(IReaderWriter param) with passing in an instance of IReaderWriter<C>. You would get a compilation error.
From point #1 and #2, this is called Invariance.
Even if you drop the TEntity Read() from the IReaderWriter<TEntity> interface, the compiler -in design time- would not allow you to call TestReadWriter(IReaderWriter param) with passing in an instance of IReaderWriter<A>. 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 <in TEntity>. This acts as a promise from you to the compiler that all members in the interface would either don’t depend on TEntity or deal with it as an input, not an output. This is called Contravariance.
Similarly, even if you drop the void Write(TEntity entity) from the IReaderWriter<TEntity> interface, the compiler -in design time- would not allow you to call TestReadWriter(IReaderWriter param) with passing in an instance of IReaderWriter<C>. 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 <out TEntity>. This acts as a promise from you to the compiler that all members in the interface would either don’t depend on TEntity or deal with it as an output, not an input. This is called Covariance.
Therefore, adding <out > or <in > makes the compiler less restrictive to serve our needs, not more restrictive as some developers would think.

Summary

At this point, you should already understand the full story of Invariance, Covariance and 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 <in > => only input => Contravariance => itself or replace with parents.
Added <out > => only 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<B> readerB = new Reader<B>();
            IReader<C> readerC = new Reader<C>();
            IWriter<A> writerA = new Writer<A>();
            IWriter<B> writerB = new Writer<B>();
            IWriter<C> writerC = new Writer<C>();
            IReaderWriter<A> readerWriterA = new ReaderWriter<A>();
            IReaderWriter<B> readerWriterB = new ReaderWriter<B>();
            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<B>
            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<B>
            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<B>
            TestReaderWriter(readerWriterB);

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

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

        public static void TestReader(IReader<B> 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<B> 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<B> 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 story as interesting as I found writing it.

This article was originally published here

DEV Community: Ahmed Tarek Hasan

🚀 Official Launch of DSP Community 🎉

🌟 What Inspired Me

👥 Join the Community

🌟 What’s in Store

📬 Subscribe to Stay Connected

💡 How You Can Support

🗣 Your Voice Matters

How to Use Observables with Vanilla JavaScript

No frameworks used, just pure vanilla JavaScript.

This is how I thought things through

Implementation

Subscription

Subject

Somewhere in the Subject Owner

Somewhere in the Observer

A Best Practice for Designing Interfaces in .NET C#

Is it enough to define IMyInterface<T>? do I need IMyInterface as well?

Is it enough to define IMyInterface<T>? do I need IMyInterface as well?

Disclaimer

Main Entity Classes

Generic Interface

Generic Interface Implementer

Inside the Employee Module

Inside the Asset Module

What About a Common Module

Wrong Expectations

This Is the Way

Let’s Give It a Test Drive

Why So Sad

The Wrong Way To Go

Moment of Truth

It Is What It Is

Resources

Covariance and Contravariance in .NET C#

Have hard time understanding it? Let me simplify it for you.

Microsoft’s Definition

What are they actually?

What if the compiler doesn’t apply any design time restrictions?

Calling TestReadWriter() when passing in an instance of IReaderWriter

Calling TestReadWriter() when passing in an instance of IReaderWriter<A>

Calling TestReadWriter() when passing in an instance of IReaderWriter<C>

The Alternative

Time for some Facts

Summary

Is it enough to define `IMyInterface<T>`? do I need `IMyInterface` as well?

Is it enough to define `IMyInterface<T>`? do I need `IMyInterface` as well?

Calling `TestReadWriter()` when passing in an instance of `IReaderWriter<A>`

Calling `TestReadWriter()` when passing in an instance of `IReaderWriter<C>`