Действительно ли это - лучшая практика для извлечения интерфейса для каждого класса?

Не думаю, что это разумно для каждого класса.

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

If является частью принципа инверсии зависимостей . В основном код зависит от интерфейсов, а не от реализаций.

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

По мере роста и усложнения вашей системы этот принцип приобретает все больший смысл!

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

Из того, что я видел, более распространено переключение реализации для тестирования (имитация), чем в реальном производственном коде. И да, это гнев для модульного тестирования.

Нет.

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

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

class Coordinate
{
  public Coordinate( int x, int y);
  public int X { get; }
  public int y { get; }
}

Вам вряд ли понадобится интерфейс ICoordinate для этого класса, потому что нет смысла реализовывать его каким-либо другим способом, кроме простого получения и установки Значения X и Y .

Однако для класса

class RoutePlanner
{
   // Return a new list of coordinates ordered to be the shortest route that
   // can be taken through all of the passed in coordinates.
   public List<Coordinate> GetShortestRoute( List<Coordinate> waypoints );
}

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

Кроме того, если у вас есть третий класс:

class RobotTank
{
   public RobotTank( IRoutePlanner );
   public void DriveRoute( List<Coordinate> points );
}

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

Однако вы увидите, что довольно легко ввести настоящие Координаты в такой тест, не скрывая их за интерфейсом ICoordinate .

Хорошо иметь интерфейсы, так как вы можете имитировать классы при (модульном) тестировании.

Я создаю интерфейсы по крайней мере для всех классов, которые связаны с внешними ресурсами (например, базой данных, файловой системой, веб-сервисом), а затем пишу макет или использую макет фреймворка для моделирования поведения.

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

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

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

Так что предварительные интерфейсы, вероятно, не лучшая идея.

Нет никаких практических причин для извлечения интерфейсов для каждого класса в вашем проекте. Это было бы чрезмерным убийством. Причина, по которой они должны извлекать интерфейсы, заключается в том, что они, кажется, реализуют принцип OOAD « Программа к интерфейсу, а не к реализации ». Более подробную информацию об этом принципе можно найти на примере здесь .

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

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

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

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

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

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