сделайте интерфейсы принадлежат собственных файлов

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

Я бы никогда не стал поместите интерфейс в тот же файл .cs, что и класс, который его реализовал.

Поскольку целью интерфейса является определение «контракта» для (потенциально) нескольких реализующих классов, я бы сказал, что размещение определения интерфейса в его собственном файле имеет больше смысла. т.е. что произойдет, если вы также хотите, чтобы Baz реализовал Foo?

У меня всего две ситуации, когда я помещаю несколько типов верхнего уровня в один файл:

• Если вы определяете несколько типов делегатов. Каждый будет только одним объявлением, поэтому имеет смысл иметь файл Delegates.cs .

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

   // Фактический код находится в автоматически созданном файле
  публичный частичный класс Foo: ICommon {}
  

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

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

Вы обязательно должны поместить интерфейс в отдельный файл. Вы даже можете рассмотреть возможность размещения интерфейса в собственной библиотеке классов. Если интерфейс будет использоваться двумя разными классами в двух разных библиотеках, имеет смысл поместить интерфейс в третью библиотеку, поэтому вам не нужно включать какую-либо конкретную реализацию, если вы хотите добавить интерфейс в новый проект. В третьей библиотеке вы также можете разместить классы, которые работают с классами, реализующими интерфейс (например, public void Cook (IBar x)).

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

Я всегда помещал их в отдельные файлы. Наличие более одного типа для каждого файла просто отвлекает ИМО. Но я мог бы сделать для них папку «Интерфейсы». Также я думаю, что вам не следует изменять их так часто, как ваши фактические реализации, так что разделение их по крайней мере немного способствует этому.