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

Question

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

Я обычно заканчиваю с:

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

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

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

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

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

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

Answer 1

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