принадлежат ли интерфейсы в собственных файлах - PullRequest
8 голосов
/ 26 июня 2009

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

, например

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

public interface IBar
{

}

public class Foo : IBar   
{

}

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

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

Ответы [ 8 ]

26 голосов
/ 26 июня 2009

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

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

3 голосов
/ 26 июня 2009

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

2 голосов
/ 26 июня 2009

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

2 голосов
/ 26 июня 2009

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

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

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

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

2 голосов
/ 26 июня 2009

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

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

1 голос
/ 26 июня 2009

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

1 голос
/ 26 июня 2009

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

0 голосов
/ 26 июня 2009

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

...