Правильное назначение пространств имен (с предложениями ReSharper) - PullRequest
2 голосов
/ 17 июня 2009

Допустим, у нас есть следующие file и структура [папка] в проекте с основным пространством имен MyNamespace:

  • [Объекты]
    • Article.cs
    • Category.cs
  • [Интерфейсы]
    • IReviewable.cs
    • ISearchable.cs
  • Enumerations.cs

Согласно рекомендациям ReSharper, пространство имен классов Article и Category должно быть MyNamespace.Entities , пространство имен IReviewable и ISearchable должно быть MyNamespace.Interfaces и пространство имен для класса Enumerations должно быть просто MyNamespace .

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


Что вы думаете о вышеупомянутых пространствах имен? Как вы думаете, правильно ли реализовывать пространства имен для классов (интерфейсов и т. Д.) Исключительно в месте их папок?

Или вы думаете, что объявление пространства имен не должно зависеть исключительно от структуры папки?

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

Ответы [ 3 ]

10 голосов
/ 17 июня 2009

Я думаю, что предложения РеШарпера в порядке. Я считаю ошибкой группировать занятия и т. Д. По тому, что они делают, а не по тому, что они делают.

Аналогия - группировка документов в подпапках Word, Excel и т. Д. Вместо Project или какой-либо другой функциональной группировки.

4 голосов
/ 17 июня 2009

Обратите внимание, что ReSharper добавляет свойство «Namespace Provider» к каждой папке в вашем проекте. Можно установить для этого свойства значение false для папки, которую вы хотите использовать для организации, но не вносить вклад в пространства имен.

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

Хорошей практикой является организация файлов в значимых папках и создание пространства имен из этой структуры. В течение многих лет Java следовала этому правилу, и это хорошо.

Также обратите внимание, что, когда у вас много подпространств имен, как указано выше, пришло время подумать об выравнивании, как это предложил Патрик (ну, вы его знаете?)

http://codebetter.com/blogs/patricksmacchia/archive/2009/02/15/re-factoring-re-structuring-and-the-cost-of-levelizing.aspx

...