Каждый интерфейс явно реализован? (Задействован IoC)

Question

Я очень осведомлен о том, что такой вопрос, вероятно, уже был опубликован. Тем не менее с участием IoC в этом случае и большого количества кода я видел коллегу в компании, в которой я новичок, поставил этот вопрос.

Сценарий:

В кодовых одного продукта этот коллега построить каждый интерфейс реализован в явном виде. Все приложение строится с помощью структурной карты, но в некоторых местах используются конкретные типы и отливать, как этот

((IInterface)concreteClass).SomeMethod() 

Справочная информация:

что коллега объяснил мне, после выяснения того, что речь идет о явном внедряя все интерфейсы, которые недавно представили StructureMap, и многие люди все равно будут использовать конкретные типы. Таким образом, по сути, это средство «воспитывать» людей в компании.

Мои центах по этому вопросу:

Прежде всего, переход на StructureMap было сделано несколько лет назад и в то время как это, своего рода, заставляет использовать интерфейсы более, на мой взгляд, это не правильно. То, как я это вижу, люди, которые знают о конкретном типе, могут увидеть реализацию и легко понять то, что я показал выше ... просто бросьте ее. Четкие соглашения об обмене или кодировании сделают это намного лучше. Если используется IoC и нет конкретного класса, то явно имплицирование интерфейса совершенно бесполезно.

Я также слышал, что это действительно может испортить наследование, но не знаю примера. Я также видел Jon Skeet отчасти не рекомендуется использовать его так, как это было упомянуто выше, а скорее способом, которым он предназначался использовать, например, с IEnumerable <> и другими столкновениями имен.

Может ли кто-нибудь пролить свет на этот вопрос для меня. Плюсы и минусы (хотя я очень предвзятый, чтобы не делать этого, следовательно, мой пост здесь) и особенно причины, почему тот или другой.

Спасибо!

Редактировать: Я очень хорошо знаю, что это не вопрос правильного или неправильного, и нет реального ответа. Это больше вопрос, чтобы научиться знать дефицит каждого подхода. Почему я должен использовать один сценарий по другому?

Answer 1

Хорошей отправной точкой может быть эта статья: Why I use explicit interface implementation as a default implementation technique

Изначально я не был склонен по реализации интерфейсов в явном виде, но я должен признать, что автор делает некоторые очень хорошие моменты.

UPDATE: В комментариях ниже OP заявляет, что явная реализация наводит наследование, поскольку вы не можете переопределить реализацию интерфейса в производном типе.Я не уверен, если я правильно допер вопрос:

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

Есть два основные потенциальные преимуществ для явных реализаций интерфейса:

1. Один класса может реализовать два интерфейса, которые имеют противоположные сигнатуры методы , и тонко разные реализации для каждого. Это редко случается, и обычно это не проблема, а не по умолчанию.
2. Вы можете «скрыть» определенные методы, которые вы не ожидаете от людей, кроме как в определенных контекстах. Принцип децентрализации интерфейса побуждает нас не раскрывать методы для потребителей, которых они вряд ли понадобятся.

Один хороший пример # 2 используется путь, который Entity Framework контексты не подвергать их основной ObjectContext непосредственно (потому что большинство людей не должны использовать его в своем коде), но до сих пор делают это свойство доступно, если вам переведите контекст на IObjectContextAdapter.

В случае вашей компании это звучит так, будто они пытаются использовать # 2, но по неправильным причинам. Они хотят скрыть реализации методов, а не потому, что метод не предполагается использовать, но потому, что они do ожидают, что он будет использоваться - и когда это так, они надеются, что это побудит разработчиков отделить их код от конкретные типы. Ваш пример кода указывает на отсутствие метки - разработчики все еще создают конкретные типы и затем бросают их, чтобы получить доступ к методам интерфейса.