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

Question

Как правило, я обычно кладу классы в свой собственный файл. Визуальная студия, похоже, поощряет это, но что подходит в отношении интерфейсов?

например.

У меня есть класс Foo, который реализует интерфейс Бар

public interface IBar 
{ 

} 

public class Foo : IBar 
{ 

} 

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

Что подходит?

Answer 1

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

Представьте, что вы пытаетесь найти класс Foo в файле с именем IBar.cs или наоборот.

Answer 2

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

  // Actualy code is in the autogenerated file 
  public partial class Foo : ICommon {} 
  

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

Answer 6

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

Answer 7

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

Answer 8

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