В какое пространство имен необходимо поместить интерфейсы относительно их конструкторов?

Я обычно сохраняю интерфейс в том же пространстве имен как конкретные типы.

Но, это - просто мое мнение, и расположение пространства имен очень субъективно.

Animals
|
| - IAnimal
| - Dog
| - Cat
Plants
|
| - IPlant
| - Cactus

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

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

Interfaces
|--IAnimal
|--IVegetable
|--IMineral
MineralImplementor
Organisms
|--AnimalImplementor
|--VegetableImplementor

Это - просто способ, которым я сделал это в прошлом, и у меня не было многих проблем с ним, хотя по общему признанию это могло бы сбивать с толку других, садящихся с моими проектами. Мне очень любопытно видеть то, что делают другие люди.

Я предпочитаю сохранять свои интерфейсы и классы реализации в том же пространстве имен. Когда возможно, я даю классам реализации внутреннюю видимость и обеспечиваю фабрику (обычно в форме статического метода фабрики, который делегирует к классу рабочего с внутренним методом, который позволяет модульным тестам в друге блок заменять другим рабочим, который производит тупики). Конечно, если реальный класс должен быть общедоступным - например, если это - абстрактный базовый класс, затем это прекрасно; я не вижу оснований для помещения ABC в ее собственное пространство имен.

На ноте стороны мне сильно не нравится конвенция.NET снабжения предисловием имен интерфейса с буквой 'я'. Вещь (I) модели интерфейса Foo не являются ifoo, это - просто нечто. Итак, почему я не могу только назвать это Foo? Я затем называю классы реализации а именно, например, AbstractFoo, MemoryOptimizedFoo, SimpleFoo, StubFoo и т.д.

Разделите интерфейсы в некотором роде (проекты в Eclipse, и т.д.) так, чтобы было легко развернуть только интерфейсы. Это позволяет Вам обеспечивать свой внешний API, не обеспечивая реализации. Это позволяет зависимым проектам создать с абсолютным минимумом внешнего облика. Очевидно, это применяется больше к большим проектам, но понятие хорошо во всех случаях.

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

Относительно пространств имен я сохраняю их в BusinessCommon. Интерфейсы.

Я делаю это, чтобы гарантировать, что ни я, ни мои разработчики не испытываем желание сослаться на реализации непосредственно.

Я обычно разделяю их на два отдельных блока. Одна из обычных причин интерфейса состоит в том, чтобы иметь серию объектов, выглядят одинаково к некоторой подсистеме Вашего программного обеспечения. Например, у меня есть все свои Отчеты, реализовывая Интерфейсы IReport. IReport используется, не используется только в печати, но для предварительного просмотра и выбора отдельных опций для каждого отчета. Наконец у меня есть набор IReport для использования в диалоговом окне, где пользователь выбирает, какие отчеты (и опции конфигурирования) они хотят распечатать.

Отчеты находятся в отдельном блоке и IReport, механизме Предварительного просмотра, механизме печати, выборы отчета находятся в своем соответствующем базовом блоке и/или блоке UI.

При использовании Класса Фабрики для возврата, список доступных отчетов в блоке отчета, затем обновляющем программное обеспечение с новым отчетом, становится просто вопросом копирования нового блока отчета по оригиналу. Можно даже использовать API Reflection, чтобы просто просканировать список блоков для любых Фабрик Отчета и создать список Отчетов тот путь.

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

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