Как организовать Интерфейсы / Классы / Реализации в проекте

Question

Я нашел несколько вопросов о том, как организовать проекты (пространство имен, один класс на файл и т. Д.), Но на более конкретном замечании, как вы организуете «вещи», которые очень тесно связаны?

Я обычно получаю:

• интерфейс IMyStuff
• a базовый (иногда абстрактный) класс , предоставляющий базовый скелет для этого интерфейса: BaseMyStuff
• классы реализации MyStuffWithBellsAndWhistles, MyStuffWithChocolateFlavours

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

Можно ли определить интерфейс и базовый класс в одном файле?

Или можно ли группировать эти вещи в подпапках, но в одном и том же пространстве имен ? как это:

-MyNamespace
 |-Interfaces
   | -IMyStuff
   | -IMyOtherStuff
 |-BaseClasses
   | -BaseMyStuff
   | -BaseMyOtherStuff
 |-Implementation
   | -MyStuffWithAwesomeBehaviour
   | -MyStuffWithGreatUsefulness
   | -MyOtherStuffSoNeatYouWillCry

Каковы "лучшие практики" в отношении такого рода организаций?

Answer 1

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