Шаблоны интерфейса расширения - PullRequest
Новая
       45

Шаблоны интерфейса расширения

23 голосов
/ 11 августа 2008

Новые расширения в .Net 3.5 позволяют отделить функциональность от интерфейсов.

Например, в .Net 2.0 

public interface IHaveChildren {
    string ParentType { get; }
    int ParentId { get; }

    List<IChild> GetChildren()
}

Может (в 3.5) стать: 

public interface IHaveChildren {
    string ParentType { get; }
    int ParentId { get; }
}

public static class HaveChildrenExtension {
    public static List<IChild> GetChildren( this IHaveChildren ) {
        //logic to get children by parent type and id
        //shared for all classes implementing IHaveChildren 
    }
}

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

Единственным недостатком является то, что реализация абстрактных основ может быть виртуальной, но можно ли обойти эту проблему (будет ли метод экземпляра скрывать метод расширения с тем же именем? Это будет сбивать с толку код?)

Есть ли другие причины не использовать этот шаблон регулярно?

Пояснение:

Да, я вижу тенденцию использования методов расширения в том, чтобы везде их использовать. Я был бы особенно осторожен с любыми типами значений .Net без большого количества экспертных проверок (я думаю, что единственное, что у нас есть в строке, это .SplitToDictionary() - аналогично .Split(), но с разделителем ключ-значение )

Я думаю, что там есть целая дискуссия о лучших практиках; -)

(Между прочим: DannySmurf, ваш премьер-министр звучит страшно.)

Я специально спрашиваю здесь об использовании методов расширения, где ранее у нас были методы интерфейса.

Я стараюсь избегать множества уровней абстрактных базовых классов - классы, реализующие эти модели, в основном уже имеют базовые классы. Я думаю, что эта модель может быть более удобной в обслуживании и менее перегруженной, чем добавление дополнительных иерархий объектов.

Это то, что MS сделала с IEnumerable и IQueryable для Linq?

Ответы [ 11 ]

0 голосов
/ 11 августа 2008

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

Даже на моей собственной работе я мог видеть, как это происходит, с желанием моего руководителя добавить каждый бит кода, над которым мы работаем, либо в пользовательский интерфейс, либо на уровень доступа к данным, я мог видеть, что он настаивает на 20 или 30 методах добавляются в System.String, которые только косвенно связаны с обработкой строк.

Страница:
...