Вопрос относится к пакетированию в .NET. Ситуация следующая: имеется множество интерфейсов сервисов; для каждого сервиса есть по крайней мере одна реализация. Как правильно разбить такую структуру на сборки. С одной стороны, так как для каждого интерфейса может быть несколько разных реализаций, то нужно поместить все интерфейсы в одну сборку, а реализации — в другую. Но, с другой стороны, принцип общего закрытия гласит, что изменения одного пакета вызывать изменения другого. Но если изменяется интерфейс, то должна измениться и реализация! Значит ли это, что интерфейс и реализацию лучше разместить в одном проекте/сборке?
Нужно ли располагать интерфейс и его реализацию в разных сборках (.NET)?
Новые ответы
Несмотря на наличие строгих принципов пакетирования и метрик, отражающих эффективность разделения классов по пакетам, на этот вопрос нет однозначного ответа. Большинство разработчиков решают эту задачу так:
Интерфейс выделяется в отдельную сборку если он достаточно общий (не связан по смыслу с другими классами проекта) или если предполагается наличие нескольких реализаций (возможно сторонних) этого интерфейса.
Интерфейс располагается в одной сборке с реализацией когда этот интерфейс служит лишь для уменьшения связанности классов внутри проекта и предполагает наличие только одной реализации.
Если я правильно понял, то лучше вынести интерфейсы в отдельную сборку и использовать версионность. Для каждого нового пакета интерфейсов просто менять версию сборки интерфейсов и реализаций к ним, тогда и старые и новые реализации будут загружать только те версии сборок, с которыми они ладят