Интерфейсы и управление версиями
-
09-06-2019 - |
Вопрос
Я проектирую новую систему, и у меня есть множество интерфейсов, которые со временем будут расширяться вместе с системой.Как лучше всего называть эти интерфейсы
ISomethingV01
ISomethingV02
etc
и я делаю это
public interface ISomething{
void method();
}
тогда мне нужно добавить метод 2, и что мне теперь делать?
public interface ISomethingV2:ISomething{
void method2();
}
или так же по-другому?
Решение
В идеале вам не следует менять интерфейсы очень часто (если вообще).Если вам действительно нужно изменить интерфейс, вам следует пересмотреть его назначение и посмотреть, применимо ли к нему исходное имя.
Если вы все еще чувствуете, что интерфейсы изменятся, а изменения в интерфейсах небольшие (добавление элементов) и вы контролируете всю базу кода, то вам следует просто изменить интерфейс и исправить все ошибки компиляции.
Если ваше изменение связано с изменением способа использования интерфейса, вам необходимо создать отдельный интерфейс (скорее всего, с другим именем) для поддержки этого альтернативного шаблона использования.
Даже если вы в конечном итоге создадите ISomething, ISomething2 и ISomething3, потребителям ваших интерфейсов будет сложно понять, в чем различия между интерфейсами.Когда им следует использовать ISomething2, а когда — ISomething3?Затем вам придется приступить к процессу устаревания ISomething и ISomething2.
Другие советы
Я думаю, вы злоупотребляете интерфейсами.
Мейер и Мартин сказали нам:«Открыто для расширения, но закрыто для модификации!»
а затем Квалина (и др.) повторили:
Из Руководства по проектированию фреймворка...
В целом, классы являются предпочтительной конструкцией для разоблачения абстракций.Основным недостатком интерфейсов является то, что они гораздо менее гибкие, чем классы, когда речь идет о допуске эволюции API.Как только вы отправите интерфейс, набор его членов зафиксирован навсегда.Любые дополнения к интерфейсу будут нарушать существующие типы, реализующие интерфейс.
Класс предлагает гораздо большую гибкость.Вы можете добавить участников в занятия, которые уже отправились.Пока метод не является абстрактным (т. Е. Пока вы предоставляете реализацию метода по умолчанию), любые существующие производные классы продолжают функционировать без изменений.
я согласен с Гаро Ериазарян, смена интерфейса - серьезное решение.Кроме того, если вы хотите продвигать использование новой версии интерфейса, вам следует пометить старую версию как устаревшую.В .NET вы можете добавить Устаревший атрибут.
Цель интерфейса — определить абстрактный шаблон, который должен реализовать тип.
Было бы лучше реализовать как:
public interface ISomething
public class Something1 : ISomething
public class Something2 : ISomething
Вы не получаете ничего в виде возможности повторного использования кода или масштабируемости дизайна, создавая несколько версий одного и того же интерфейса.
Я не знаю, почему люди минусуют ваш пост.Я думаю, что хорошие рекомендации по именованию очень важный.
Если вам необходимо сохранить совместимость с предыдущим.версию того же интерфейса рассмотрите возможность использования наследования.Если вам необходимо представить новую версию интерфейса, учитывайте следующее правило:
Попробуйте добавить значимый суффикс к вашему интерфейсу.Если невозможно создать краткое имя, рассмотрите возможность добавления номера версии.