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

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

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: Я понимаю, что явная реализация интерфейса очень важна, и его можно использовать, когда нам нужно предоставить доступ к методу только на уровне интерфейса и использовать два интерфейса с одной и той же сигнатурой метода.

Ответы

Ответ 1

Угу. Выглядит излишним.

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

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

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

Ответ 2

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

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

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