Должны ли вы создавать интерфейс, когда (в настоящее время) будет только один класс, который его реализует?

Это всегда зависит от ситуации. Если вы ЗНАЕТЕ, что будет другой класс, использующий интерфейс, тогда да, создайте класс интерфейса, чтобы сэкономить время позже. Однако, если вы не уверены (а в большинстве случаев это не так), подождите, пока вам это не понадобится.

Теперь это не означает игнорировать возможность интерфейса - подумайте об общедоступных методах объекта и тому подобном с прицелом на создание интерфейса позже, но не загромождайте свою кодовую базу тем, что вам на самом деле НЕ НУЖНО.

Всегда будет тест, который его использует, верно (вы делаете модульные тесты, не так ли?). Это означает, что его всегда используют N + 1 класс, где N — количество классов, использующих ваш класс в приложении.

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

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

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

Например, команда библиотеки базовых классов .NET Framework признала преждевременное проектирование ICollection, когда оно включало свойство SyncRoot. Для более позднего универсального ICollection<T> они решили удалить его (http://blogs.msdn.com/bclteam/archive/2005/03/15/396399.aspx).

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

Я бы сказал, что это больше зависит от того, в скольких местах вы собираетесь использовать класс, и меньше от того, сколько классов могут реализовать интерфейс. Если вы используете папку только в одном или двух местах, я бы сказал, подождите, пока не возникнет реальная потребность в интерфейсе, прежде чем реализовывать его и проводить рефакторинг. Однако, если Folder будет использоваться в 100 разных местах, вы можете сэкономить время, заранее запрограммировав интерфейс.

Думайте об интерфейсе как о контракте для определения семантики или концепции. Это общий подход, а не конкретный язык. В контексте объектно-ориентированного программирования, если вы работаете с одной моделью наследования, есть отличный повод предпочесть интерфейсы классам для определения вашей объектной модели, поскольку этот единственный путь суперкласса довольно ценен, и вы хотите сохранить его для что-то более «существенное», чем определение свойств, предоставляемых объекту или методам.

Наличие семантики IContainer (контракта) — довольно плохая причина для создания интерфейса из вашей папки; лучше, чтобы ваша папка (если она выполняет какую-либо нетривиальную логику) «реализовала» (вероятно, уже существующий) интерфейс IContainer или ICollection в основных структурах вашего языка.

Как всегда, лучший выбор в значительной степени зависит от конкретной проблемы. В случае ваших рецептов, которые также являются папками (?!), вы, вероятно, имеете в виду отношения родитель-потомок или композиция, отношения - семантика, которая может (и должна) быть выражена с помощью интерфейсов, если в вашей системе будут другие элементы. «действовать» над вещами, составленными с использованием такой семантики.

Интерфейсы сопряжены с некоторыми накладными расходами (с точки зрения программирования), и если вы обнаружите, что, закончив работу, не имеете ничего, кроме набора классов и интерфейсов Woof и IWoof, то вы поймете, что вам, вероятно, не нужно было выражать ваша проблема с интерфейсами - было бы достаточно простых классов.

Как правило, для любого I у вас должна быть как минимум пара конкретных классов (с более осмысленными именами, отличными от IImpl или ).

Надеюсь, это поможет.

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