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