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 into 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. 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 method. Initialize It has a method which expects an integer parameter and returns a . Read(int dataId) TData It has method which expects a parameter. Write(TData data) TData 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 data, let’s call this module; . Employee Employee Module Inside the , you are sure of the type of data you are dealing with, it is obviously of type . Employee Module 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 data, let’s call this module; . Asset Asset Module Inside the , you are sure of the type of data you are dealing with, it is obviously of type . Asset Module 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 method. Inside this method, you want to call the method of the passed in parameter. Run(IReaderWriter readerWriter) Initialize readerWriter 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 interface. In other words, we only have , not . IReaderWriter IReaderWriter<TData> IReaderWriter Wrong Expectations Now, I can hear someone shouting from a far distance saying: . Every class is a child of Object, right?….. genius. Huh, it is a piece of cake. Let’s use IReaderWriter<object> My answer to him is that he should do his homework as this is not going to work. If you don’t trust me on this, just give it a try and you will see the following: You need more explanation right, the short answer is that your interface is you can’t call a method expecting and pass in an instance of . The only acceptable call would be with passing , nothing else. Invariant; IReaderWriter<SomeClass> IReaderWriter<AnyOtherClass> IReaderWriter<SomeClass> This Is the Way Now you understand why we need to define a non-generic interface. IReaderWriter 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 method as this is what we actually need in the common module or even the new ones if they come in the future. Initialize() Now the other generic interface can safely extend the non-generic one with the and methods without changing anything on the signature. Read Write 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 coming in and the common module needs some modifications. The common module now should be able to . The Blob storage can store any kind of data. new requirements store and retrieve data in and from a Blob storage 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 interface doesn’t define the and methods. They are defined in the . However, on the common module and at the moment of calling and methods, we don’t know the type of data. So, what to do!!! IReaderWriter Read Write IReaderWriter<TData> StoreInBlob RetrieveFromBlob 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 object so that you can access its unique members, like as in the image. Employee EmployeeName Similarly, you have to cast your object so that you can access its unique members, like as in the image. Asset AssetName So, now what???? Moment of Truth The keyword for the best solution here is the word . Let me break it down for you. new 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 interface now defines are the required methods. IReaderWriter However, for the and methods, they are now using the parent entity type. Read Write Data The interface now extends the interface. IReaderWriter<TData> IReaderWriter This means that it also indirectly defines the three methods we know about. However, inside the interface, we need to use the generic type , not the parent . IReaderWriter<TData> TData Data To do so, we need to add and methods to the interface. TData Read(int dataId); void Write(TData data); IReaderWriter<TData> 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 a different return type. This would confuse the compiler at run time as it would not know which method to call, the one returning or the other one returning . Data TData That’s why the compiler would not allow you to do so unless you add the keyword at the start of the method definition as in the code above. new This instructs the compiler to hide the method inherited from the parent and replace it with the one defined after the keyword. Read new Now, you might ask, why didn’t we do the same with the method? Write The answer is simply that we don’t need to do so. In the parent interface, we already have a method called which expects a parameter of type which is the parent of all types that could be passed in to the method. Write Data Write This means that this method could be called passing any could come. TData Another thing, if you try to use the keyword with the method, you would get a warning that you are actually not hiding anything from the parent interface. This is logical as the two methods have different input parameter types, so, it is sound and clear to the compiler that they are two different methods. new Write Write 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 of the method defined in the parent interface. explicit implementation Data Read(int dataId); IReaderWriter This means that whenever an object of the class is casted, implicitly or explicitly, as the non-generic interface , this method implementation would be used. FileReaderWriter<TData> IReaderWriter Read The second method is . void IReaderWriter.Write(Data data) { Write((TData)data); } This method is an of the method defined in the parent interface. explicit implementation void Write(Data data); IReaderWriter This means that whenever an object of the class is casted, implicitly or explicitly, as the non-generic interface , this method implementation would be used. FileReaderWriter<TData> IReaderWriter Write 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 and ? IEnumerable IEnumerable<T> Could you imagine what life would be like if we didn’t have :) ? IEnumerable This would mean that you can’t write code that 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 that accepts and then it would pass it to the , 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. <T> IEnumerable<T> Therefore, my final advice to you is don’t try to beat around the bush, it is what it is… That’s it, hope you found reading this article as interesting as I found writing it. Also published here.

The Difference Between Covariance and Contravariance in .NET C#

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

Make resilience your competitive advantage

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?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

A Better Implementation of Enhanced Repository Pattern in .NET C#

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Every React Developer

10 Best Practices for Using Kubernetes Network Policies

12 Essential Coding Standards for Quality Web Development

A Better Implementation of Enhanced Repository Pattern in .NET C#

10 Reasons Why Less Is More in Your init/deinit Methods

10 Best Practices for Every React Developer

10 Best Practices for Using Kubernetes Network Policies

12 Essential Coding Standards for Quality Web Development

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps