Должны ли все объекты иметь интерфейс?

Question

У меня возникли некоторые проблемы с чрезмерным использованием интерфейсов в приложении, которое я разрабатываю. Это приложение для отчетов, которое просто выполняет инструкции SQL и анализирует некоторый XML, который сохраняет свойства столбца.

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

interface IFoo 
{ 
    IBar GetBar(); 
} 

class FooA : IFoo 
{ 
    IBar GetBar() 
    { 
     return new BarA(); 
    } 
} 

class FooB : IFoo 
{ 
    IBar GetBar() 
    { 
     return new BarB(); 
    } 
} 

Я понимаю преимущество для развития таким образом, для классов, которые содержат конкретные детали реализации, но следует этому шаблон будет применяться для каждого класса в моем приложении?

Вот (упрощенный) пример из моего приложения:

interface IColumnDefinition 
{ 
    int Ordinal { get; } 
    string HeaderColor { get; } 
} 

class ColumnDefinition : IColumnDefinition 
{ 
    private readonly int _ordinal; 
    private readonly string _headerColor; 

    public int Ordinal { get { return _ordinal; } } 
    public string HeaderColor { get { return _headerColor; } } 

    public ColumnDefinition(int ordinal, string headerColor) 
    { 
     _ordinal = ordinal; 
     _headerColor = headerColor; 
    } 
} 

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

Microsoft не использует интерфейс в своих System.Data.DataColumn или для своих System.Windows.Forms.DataGridViewColumn, имеет ли смысл использовать его и почему?

PS: пожалуйста, не распинайте меня, говоря, что, поскольку Microsoft ничего не делает, я тоже не должен - это всего лишь два примера похожих объектов, которые широко используются, созданные людьми, которые знают намного больше о программировании, чем И.

Answer 1

Извлечение интерфейсов от того, что в основном объекты передачи данных действительно избыточна в типичном случае (со всеми вещами, там есть исключения). Вы хотите до код к интерфейсу для классов, которые выражают логику, логику, что вы хотите иметь гибкость при замене по тем или иным причинам (например, модульные тесты!). Но если класс, который вы заменяете, содержит только данные, просто используйте класс. Если позже вы обнаружите, что вам нужно внедрить содержательную логику, в это время идите и извлеките интерфейс, если он вам поможет.

Чтобы было ясно, я не ожидал бы ColumnDefinition, как вы определили, чтобы реализовать интерфейс, не больше, чем я ожидал бы работать с интерфейсами вместо string, int или DateTime (*). Код, который действует в отношении экземпляров ColumnDefinition, я хотел бы найти реализацию интерфейса, особенно если и когда я хочу избавиться от этой конкретной логики (когда я тестирую другой код, который зависит от него, или если что другой код должен быть открыт для расширения и т. д.).

---

* Я иногда найти необходимость замены DateTIme.Now, но не требует интерфейса на DateTime типа специально.

Answer 2

Как мне кажется, если вы не намерены использовать полиморфизм в этом конкретном случае, нет причин иметь интерфейс для КАЖДОГО объекта.

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

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

Answer 3

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

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

Конечно, если вы не можете знать, тогда вам должно быть предоставлено образованное предположение.

---

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

Answer 4

Некоторые утверждают, что все объекты do имеют интерфейс - независимо от того, используют ли они совместно используемые interface или нет. Неличные методы/свойства класса могут считаться его «интерфейсом».

Одна из причин (предположительно), почему DataColumn НЕ определяет interface, поскольку он предназначен для одной цели - определить столбец DataTable. Дизайнеры класса DataTable, вероятно, не видели значения абстрагирования от определения DataTable и позволяли использовать несколько реализаций.

Используйте interface сек , где они имеют смысл - в любое время вы хотите, чтобы иметь возможность окурок или макет для модульного тестирования, когда несколько реализаций класса было бы полезно (например, IDataReader) и т.д. Если иметь интерфейс обеспечивает нет значения, то не беспокойтесь. Существует несколько инструментов, таких как Resharper, которые обеспечивают простой механизм для извлечения общедоступных методов/свойств в классе в интерфейс, который должен понадобиться позже.

Имея interface для каждого класса, вероятно, будет излишним.