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

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

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

public interface ISomething

public class Something1 : ISomething
public class Something2 : ISomething

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

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

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

Try to add meaningful suffix to you interface. If it's not possible to create concise name, consider adding version number.

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

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

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

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

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

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

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

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

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

In general, classes are the preferred construct for exposing abstractions. The main drawback of interfaces is that they are much less flexible than classes when it comes to allowing for evolution of APIs. Once you ship an interface, the set of its members is fixed forever. Any additions to the interface would break existing types implementing the interface.

A class offers much more flexibility. You can add members to classes that have already shipped. As long as the method is not abstract (i.e., as long as you provide a default implementation of the method), any existing derived classes continue to function unchanged.