Интерфейсы в файлах классов

Если есть только одна реализация: зачем интерфейс?

Если существует более одной реализации: куда поместить остальные?

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

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

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

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

Отдельные файлы ... FTW! Возможно, вы даже захотите создать отдельные проекты / сборки в зависимости от того, насколько расширяем ваш код. По крайней мере, он, вероятно, должен быть в отдельном пространстве имен.

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

Но, как отмечает @balabaster, это зависит от практик вашей команды (хотя они не всегда являются «лучшими практиками»).

Да, для классов они называются partial class, посмотрите текст ссылки

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

Более того, в зависимости от уровня разделения и изоляции вашего приложения вы даже можете захотеть использовать разместите свои интерфейсы в собственном проекте. Тогда потребляющие проекты будут ссылаться на проект интерфейса, а не на каждую сборку, которая несет реализации этого интерфейса.

Да, даже если кто-то приводит встречные аргументы, например, есть только одна реализация, или он / она предвидят, что будет только одна реализация в течение длительного времени, или он / она является единственным пользователем / разработчиком и т. д. Если существует несколько реализаций, несколько пользователей и т. д., то очевидно, что вы захотите сохранить их в отдельных файлах. Так почему же нужно относиться к нему по-разному в случае только одной реализации?