Is each interface explicitly implemented? (IoC participation)

Question

I know very well that such a question has probably already been published. Nevertheless, with the participation of IoC in this case and a lot of code, I saw a colleague in the company where I am new, made this question.

Scenario:

In the code base of one product, this colleague builds each interface, is implemented explicitly. The entire application is built on a structural map, but in some places specific types are used and such as

((IInterface)concreteClass).SomeMethod() 

Background:

This colleague explained to me by asking that this concerns the explicit implementation of all interfaces, that they recently introduced StructureMap, and many people will still only use specific types. Thus, in essence, this is a means of “educating” people in a company.

My cents on this issue:

First of all, the transition to StructureMap was made a few years ago, and although this seems to make us use interfaces more, in my opinion, this is the wrong way. The way I see it, people who know about a particular type can see the implementation and easily understand what I showed above ... just drop it. Clear exchange or coding conventions will make this much better. If IoC is used and there is no specific class, then explicitly implanting an interface is completely useless.

I also heard that this can really ruin the inheritance, but I don't know an example. I also saw how John Skeet did not encourage him to be used as mentioned above, but rather the way he was intended to be used, for example with IEnumerable <> and other name conflicts.

Can someone shed some light on this question for me. Pros and cons (although I am very biased not to do this, therefore, my post is here) and especially the reasons why this or that.

Thanks!

Edit: I know very well that this is not a question of right or wrong, and there is no real answer. It is more a question to learn to know the scarcity of each approach. Why should I use one script for a different approach?

Answer 1

This article can be a good starting point: Why I use an explicit interface implementation as the default implementation method

Initially, I was not explicitly configured to implement interfaces, but I must admit that the author makes very good points.

UPDATE In the comments below, the OP states that an explicit implementation induces inheritance, since you cannot override an interface implementation in a derived type. I am not sure if I am fixing the problem correctly:

 public interface IFooable { void Foo(); void FooAgain(); } public class Blah: IFooable { void IFooable.Foo() { Console.WriteLine("Hi from 'Blah'!"); } void IFooable.FooAgain() {} } public class Bar: Blah, IFooable { void IFooable.Foo() { Console.WriteLine("Hi from 'Bar'!"); } } public static void Main() { var fooList = new List<IFooable>(); fooList.Add(new Blah()); fooList.Add(new Bar()); foreach (var fooable in fooList) //Outputs "Hi from 'Blah'!" / "Hi from 'Bar'!" fooable.Foo(); Console.ReadLine(); } 

Answer 2

There are two main potential benefits to explicit interface implementations:

• One class can implement two interfaces that have conflicting method signatures and subtly different implementations for each. This rarely happens, and it is usually not a problem to execute on demand, and not by default.
• You can “hide” certain methods that you do not expect to be used by people, except in certain contexts. The principle of separation of segments encourages us not to disclose methods for consumers, which they are unlikely to need.

One good use case for # 2 is how Entity Framework contexts do not directly expose them to the underlying ObjectContext (because most people should not use it in their code), but make this property available if you create a context for the IObjectContextAdapter .

In the case of your company, it sounds like they are trying to use # 2, but for the wrong reasons. They want to hide method implementations, not because the method is not intended to be used, but because they expect it to be used. And when he hopes, he will encourage developers to separate their code from specific types. Your sample code indicates that it lacks a label - developers still create specific types and then drop them to access the interface methods.