Интерфейсы и управление версиями

Question

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

ISomethingV01
ISomethingV02
etc

и я делаю это

public interface ISomething{
      void method();
}

тогда мне нужно добавить метод 2, и что мне теперь делать?

public interface ISomethingV2:ISomething{
      void method2();
}

или так же по-другому?

Answer 1

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

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

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

Даже если вы в конечном итоге создадите ISomething, ISomething2 и ISomething3, потребителям ваших интерфейсов будет сложно понять, в чем различия между интерфейсами.Когда им следует использовать ISomething2, а когда — ISomething3?Затем вам придется приступить к процессу устаревания ISomething и ISomething2.

Answer 2

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

Мейер и Мартин сказали нам:«Открыто для расширения, но закрыто для модификации!»

а затем Квалина (и др.) повторили:

Из Руководства по проектированию фреймворка...

В целом, классы являются предпочтительной конструкцией для разоблачения абстракций.Основным недостатком интерфейсов является то, что они гораздо менее гибкие, чем классы, когда речь идет о допуске эволюции API.Как только вы отправите интерфейс, набор его членов зафиксирован навсегда.Любые дополнения к интерфейсу будут нарушать существующие типы, реализующие интерфейс.

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

Answer 3

я согласен с Гаро Ериазарян, смена интерфейса - серьезное решение.Кроме того, если вы хотите продвигать использование новой версии интерфейса, вам следует пометить старую версию как устаревшую.В .NET вы можете добавить Устаревший атрибут.

Answer 4

Цель интерфейса — определить абстрактный шаблон, который должен реализовать тип.

Было бы лучше реализовать как:

public interface ISomething

public class Something1 : ISomething
public class Something2 : ISomething

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

Answer 5

Я не знаю, почему люди минусуют ваш пост.Я думаю, что хорошие рекомендации по именованию очень важный.

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

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