Где хранить внутренние занятия?

Question

Предположим, я создаю новую библиотеку Jokes, с небольшим API.В целях упрощения использования моего API я поместил его в базовое пространство имен:

namespace Jokes

    --> public interface IJoker
        --> string Joke();

    --> public static class Jokers
        --> public static IJoker NewSlapstickJoker()
        --> public static IJoker NewAbsurdJoker()
        --> public static IJoker NewCheesyJoker()

Реализации джокеров являются внутренними:

--> internal class SlapstickJoker : IJoker
--> internal class AbsurdJoker : IJoker
--> internal class CheesyJoker : IJoker

---

Теперь яЯ почти уверен, что следующее является рекомендацией (может кто-нибудь проверить?):

• Не получать доступ к типам из подпространств имен из корневого пространства имен.(Например, типы в System игнорируют типы в System.Drawing).

Применимо ли это руководство к внутренним классам?Чтобы избежать загрязнения моего корневого пространства имен, я хотел бы поместить свои внутренние классы в Jokes.Internal.Это будет означать, что тип в пространстве имен Jokes (Jokers) будет знать о типах в пространстве имен Jokes.Internal.Это нормально?

Answer 1

Чтобы избежать загрязнения моего корневого пространства имен, я хотел бы поместить свои внутренние классы в Jokes.Internal.Это будет означать, что тип в пространстве имен Jokes (Jokers) будет знать о типах в пространстве имен Jokes.Internal.Это нормально?

Да, все в порядке.Основное руководство о том, что типы в пространстве имен не должны полагаться на типы в «суб» пространстве имен, на самом деле больше относится к общедоступному API.Внутренние классы и пространства имен, используемые только внутренними типами, на самом деле являются деталями реализации, и вне всяких указаний такого рода.Использование внутреннего пространства имен кажется разумным (хотя я потенциально могу сделать что-то вроде пространства имен Jokes.Implementations).

Кроме того, учитывая, что ваш класс Jokers создает новые экземпляры, это в основном фабрика.Возможно, вы захотите назвать что-то более похожее на JokerFactory, чтобы сделать это очевидным.Jokers, на мой взгляд, предполагает, что в классе будет содержаться коллекция Joker экземпляров, а не набор фабричных методов.

Answer 2

Чтобы не загрязнять корневое пространство имен, я предлагаю:

• Объявите классы internal вместо public (чтобы они не были видны пользователям вашего API).вне сборки)

• Объявите затем как вложенные внутренние классы Jokers (чтобы они не были видны вне класса Jokers)

Answer 3

Пространства имен служат нескольким ключевым целям:

1. Они помогают избежать коллизий имен между типами, которые разные разработчики и разные организации создают и совместно используют.
2. Они помогают организовывать типы в группы для созданиялегче понять, что они делают и какие типы относятся друг к другу или используются вместе.

Теперь к вашему конкретному вопросу.Ссылка на типы во внутреннем пространстве имен из внешнего не очень желательна, но и не ужасна.Хотя сейчас я не могу вспомнить ни одного из них, я не удивлюсь, если в самой среде .NET будут случаи, когда такая ситуация существует.Как общий принцип проектирования, хорошая идея - строить код по уровням;и часто эти уровни структурированы таким образом, что менее «специализированный» код не знает о более «конкретном коде».

Вложение пространства имен - это один из способов отделения более специализированных типов от менее специализированных.Таким образом, пространство имен System содержит очень общие и широко применимые типы - тогда как System.Drawing более специализировано и содержит типы, относящиеся к изображению и визуальным манипуляциям.

Однако вам следует избегать использования пространств имен для группировкитипы на основе доступности.Это определенно является злоупотреблением пространствами имен - и, вероятно, вызовет проблемы в долгосрочной перспективе (особенно из-за того, что обычно расширяется доступность типа - но может быть довольно сложно изменить, в какое пространство имен он входит).

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

Answer 4

Ничего страшного, если вы делаете то, что предлагаете, но я думаю, что было бы лучше избегать пространства имен "Jokes.Internal". Я бы не думал, что внутренние классы «загрязняют» ваше корневое пространство имен.

Как бы то ни было, я думаю, что совершенно неортодоксально создавать пространства имен, соответствующие вашим декларациям видимости.