Неявная и явная реализация интерфейса

Question

Во время работы над обновлением я случайно наткнулся на такой код.

interface ICustomization
    {
        IMMColumnsDefinition GetColumnsDefinition();
    }

    class Customization : ICustomization
    {
        private readonly ColumnDefinition _columnDefinition;

        //More code here.

        public ColumnsDefinition GetColumnsDefinition()
        {
            return _columnDefinition;
        }

        ColumnsDefinition ICustomization.GetColumnsDefinition()  //redundant
        {
            return GetColumnsDefinition();            
        }
    }

Мой вопрос: Есть ли необходимость / использование «явной» реализации интерфейса в этом фрагменте кода? Будет ли это создавать какие-либо проблемы, если я удалю метод (явная реализация интерфейса), который я пометил как «избыточный» выше?

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

Answer 1

Да. Выглядит излишним.

Вызов его через ссылку типа настройки и тип ссылки ICustomization приводит к тому же поведению. Если вы хотите, чтобы приведенные ниже вызовы вели себя по-другому, то реализация интерфейса явно имела бы смысл.

Customization oVar = new Customization();
oVar.GetColumnsDefinition(); // calls 1st method
ICustomization iVar = obj;
iVar.GetColumnsDefinition(); // calls 2nd method - explicit impl.

Вы должны удалить явную реализацию. Однако, если вы удалите другую реализацию, вы ограничите клиентов так, что они больше не смогут вызывать oVar.GetColumnsDefintion () - они должны использовать переменную интерфейса, как показано выше.

Answer 2

Для информации, основное время, когда вы видите этот конкретный паттерн, когда (любой из):

• неявный метод - virtual или abstract, для подклассов - override
• сигнатура метода public не является совсем такой же, например, открытый API имеет более конкретный тип возврата (общий для таких вещей, как IEnumerable[<T>] или ICloneable).
• мы не хотим, чтобы он был public, но мы хотим, чтобы он легко вызывался внутри типа (без использования nop-cast)

В этом случае это действительно выглядит избыточно.