Структура проекта .Net (Java) - классы и интерфейсы

#классы #net #java

Добрый день.
Давно уже задаюсь вопросом как принято хранить абстракции (интерфейсы, абстрактные
классы) и их реализации относительно друг друга? В одной физической папке или в разных?
В одном namespace или в разных? Вот возможные варианты (Objects, Base - папки; IObject
- интерфейс; ConcreteObjectA и ConcreteObjectB - реализации интерфейса IObject).
Вариант 1 - все в одной папке и одном namespace:
  -> **Objects**
    -> IObject
    -> ConcreteObjectA
    -> ConcreteObjectB

Вариант 2 - папка Base (или подобная) для абстракций:
-> **Objects**
  -> **Base**
    -> IObject
  -> ConcreteObjectA
  -> ConcreteObjectB

Вариант 3 - папка Implementration (или подобная) для реализаций:
 -> **Objects**
   -> **Implementration**
     -> ConcreteObjectA
     -> ConcreteObjectB
   -> IObject

Вариант 4 - свой (напишу в ответе).
Какой вариант используете вы? Почему?    

Ответы

Ответ 1

Мне кажется удобным следующий вариант:


Структура папок эквивалентна неймспейсам. То есть, если неймспейс некоторого класса
выглядит как ProjectName.Dynamic.Stubs, то этот файл обязан располагаться в папке ProjectName\Dynamic\Stubs.


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


В том случае, если количество интерфейсов в отдельно взятом неймспейсе начинает превышать
9-12 штук, то их можно вынести в отдельный вложенный неймспейс Interfaces. Реализации
же, соответственно, выносятся в неймспейс Implementation или Impl.





Реальный пример, в котором произведено выделение отдельных неймспейсов для интерфейсов
и их реализаций — Rhino.Mocks.Interfaces и Rhino.Mocks.Impl.


Реальный пример, в котором такое отделение не произведено (что, кстати, не повредило
читаемости) — System.Linq, в котором есть и интерфейсы типа IQueryProvider и их конкретные
реализации типа EnumerableQuery.


Ответ 2

Это зависит от плана использования. Скажем у вас интерфейсик, который (вы уверены
в этом) будет использоваться только в пределах вашего проекта, тогда ему самое место
рядом с реализацией.
А если ваш интерфейс/абстрактный класс планируется использовать и в других проектах,
то лучше это вынести в отдельный неймспейс/пакет/каталог.
Логика здесь в следующем: если далее планируется reusability кода, то потенциальному
потребителю наверное не очень интересна ваша реализация/имплементация абстракций, соответственно
он(а) возьмет/импортирует только сами абстракции.
Пример: пакет java.sql, который содержит в себе декларации абстракций для работы
через JDBC, а их конкретная реализация всегда содержится отдельно и обычно предоставляется
вендором JDBC драйвера. Например для Oracle это пакет oracle.jdbc выглядит так