Explicit interface implementation in .NET Part 4

In the previous post we finally solved the mystery of how the Add method was “hidden” in the ConcurrentDictionary object. We now know how explicit interface implementation works in code.

However why would you implement an interface explicitly?

I can think of two reasons:

Method signatures

In C# two methods are considered the “same” if they have the same name and same input parameter types. Their return type doesn’t matter. The following code will cause the compiler to complain:

public bool Method(int i)
{
	return false;
}

public int Method(int input)
{
	return input + 2;
}

Those two methods have the same method signatures and cannot be overloaded based on their return types only. Consequently if you have two interfaces that provide methods of the same signature, like we saw before…:

public interface ISummable
{
	int Calculate(int a, int b);
}
public interface IMultipliable
{
	int Calculate(int a, int b);
}

…then the only option two implement both is to implement at least one of them explicitly. It doesn’t make any difference which. You can implement both of them explicitly as well.

Discourage usage

The above reasoning doesn’t explain why the Add method is not available directly on the ConcurrentDictionary object.

In that specific case Microsoft wanted to discourage the usage of the Add method which was meant for single-threaded usage just like in the “normal” Dictionary object. ConcurrentDictionary is meant to be used in multithreaded scenarios. The Add method was therefore explicitly implemented instead. It’s unlikely that people will declare a concurrent dictionary as an interface type:

IDictionary<string, string> concurrentDictionary = new ConcurrentDictionary<string, string>();

Therefore if you declare the ConcurrentDictionary like most people do…

ConcurrentDictionary<string, string> concurrentDictionary = new ConcurrentDictionary<string, string>();

…then you’ll be instead presented with the thread-safe TryAdd and AddOrUpdate methods so you’ll automatically be “redirected” to those methods.

So if you’d like to hide an implicit interface method from the consumers of an object an option is explicit interface implementation so that the interface method won’t be visible on the class.

This post concludes our discussion of explicit interface implementation.

View all various C# language feature related posts here.

Advertisements

About Andras Nemes
I'm a .NET/Java developer living and working in Stockholm, Sweden.

One Response to Explicit interface implementation in .NET Part 4

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

ultimatemindsettoday

A great WordPress.com site

Elliot Balynn's Blog

A directory of wonderful thoughts

Robin Sedlaczek's Blog

Developer on Microsoft Technologies

HarsH ReaLiTy

A Good Blog is Hard to Find

Softwarearchitektur in der Praxis

Wissenswertes zu Webentwicklung, Domain-Driven Design und Microservices

the software architecture

thoughts, ideas, diagrams,enterprise code, design pattern , solution designs

Technology Talks

on Microsoft technologies, Web, Android and others

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

Anything around ASP.NET MVC,WEB API, WCF, Entity Framework & AngularJS

Cyber Matters

Bite-size insight on Cyber Security for the not too technical.

Guru N Guns's

OneSolution To dOTnET.

Johnny Zraiby

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

%d bloggers like this: