Насколько важен контекст, подразумеваемый пространством имен?
Хорошо, название может показаться немного расплывчатым, но я действительно не могу придумать здесь что-то более ясное. .
Недавно мне понадобился класс Point , просто с двумя свойствами, X и Y и ctor Point ( int x, int y) . Ничего фантастического. Теперь эта штука уже существует в .NET, но это было в библиотеке, которая обрабатывала определенные объекты на карте, и перетаскивание System.Drawing в это просто казалось ... каким-то образом неправильным. Несмотря на то, что System.Drawing.Point идеально подходил для того, что мне было нужно, теперь я снова создал эту структуру в этом проекте.
Теперь мне интересно, было ли это правильным или разумным поступком. System.Drawing.Point также должен был содержать ссылку на эту сборку, если я правильно помню. А помещать что-то в System.Draw в контекст, не связанный с рисованием, было как-то странно.
Мысли? Что, если бы это не подразумевало ссылку на другую сборку?
8 ответов
Контекст пространства имен является фундаментальным в приближении к точной функции класса; класс Connection будет совсем другим от одного пространства имен к другому. Подходит ли класс Web.Cache для кэширования в других приложениях или он фундаментально зависит от веб-инфраструктуры?
MSDN описывает структуру System.Drawing.Point следующим образом:
«Представляет упорядоченную пару целочисленных x- и y-координат, которая определяет точку на двумерной плоскости».
С таким общим описанием можно утверждать, что эта структура является лишь случайной связаны с рисованием и действительно относятся к более фундаментальному пространству имен.
Однако, поскольку он существует в System.Drawing , подразумевается, что он представляет точку в двухмерном пространстве рисования. Таким образом, использование этого класса для целей, отличных от рисования, является неправильным использованием класса; он может работать для ваших нужд, но он не используется по назначению.
Я бы не сказал, что то, что вы сделали, было неправильным, однако пространство имен на самом деле является просто контейнером для объявлений, в котором каждое имя уникально, имя пространства имен действительно предоставляет некоторый контекст, чтобы помочь вам найти подходящая функция для ваших нужд, но не зацикливайтесь на контексте, который не совсем подходит для вашего использования, если объект идеален, то он идеален. Помимо оператора using, вы, вероятно, никогда больше не будете активно обращаться к пространству имен.
Если ваша цель для точки никоим образом не связана с рисованием, я думаю, вы поступили правильно. Использование System.Drawing.Point в коде, который вообще ничего не делает, связанного с рисованием, может сбить с толку людей, заставляя думать, что он используется для некоторых функций рисования.
Я бы просто использовал System.Drawing.Point. Зачем воссоздавать то, что уже существует? Кого волнует, как называется пространство имен, если оно предоставляет нужную вам функциональность. Только мои 2 цента ...
Недавно я был в похожей ситуации. Класс Point не нужен, но я буду использовать его в качестве примера.
Я создал свой собственный класс Point, потому что System.Drawing.Point использует целые числа, когда мне нужны двойники. Позже я понял, что это была хорошая идея, даже если мне были нужны только целые числа, потому что я мог затем расширять класс по мере необходимости и добавлять методы, интерфейсы, атрибуты и т. Д. В то время как я бы не смог, если бы использовал Систему .Drawing.Point.
Существует принцип, согласно которому вы не должны дублировать знания в своих программах, но в некоторых случаях, таких как этот, этого нельзя избежать.
Что касается ссылки на другую сборку, вы можете сделать это:
using Point = System.Drawing.Point; // or whatever your namespace is called
Если вы не импортируете «багаж» (например, инициализируете вещи, которые вы не используете), то это именно то, что вам нужно, я бы выбрал существующий код. Просто нет смысла воссоздавать существующий код. Скорее всего, вы позже обнаружите функции, которые выполняют функции, которые вам нужны, и ожидают этого конкретного класса.
Тем не менее, я могу отождествить себя со странным ощущением наличия в вашем коде "чужеродного" объекта. Один из способов обойти это - создать подкласс со своей собственной точкой. Это будет выглядеть немного странно, если вы ничего не меняете в своем подклассе, но это видно только в источнике этого класса, и там, где вы его используете, он имеет одинаковое имя. Кроме того, он начнет выглядеть по-настоящему умным, как только вы обнаружите, что добавляете функциональность к своей пользовательской точке.
Я бы очень не беспокоился о том, чтобы принести что-то из пространства имен, учитывая, что функционально и концептуально (как это описано в документации) это соответствует цели.
Однако я бы колебался, если бы вводил новую сборку. В данном случае тот факт, что в Point можно так быстро создать свою собственную сборку, может показаться мне менее хлопотным, чем добавление еще одной зависимости в сборку, которую я пишу.
В остальном, пока я не использую его в качестве ключа (имплант GetHashCode в Point не очень хорош в том, как он сталкивается, например, со всеми {0,1}, {1,0}, {2,3} и{3,2}, если у вас много малозначимых или прямолинейно распределенных точек), я бы использовал его.
Я не согласен с другими ответами и говорю, что это действительно имеет значение. Пример с Point прост, но в целом использование класса в контексте, для которого он не был разработан, может привести к нежелательным последствиям.
Класс мог быть реализован только для конкретного случая использования, например, без поддержки безопасности потоков, требуя использования в рамках фреймворка или раскрывая функциональность, которая нежелательна в вашем коде.
Особенно это может привести к проблемам, когда развертывается более новая версия сборки, которая больше не совместима с тем, как вы ее используете, или новая версия привносит дополнительные члены и зависимости, которые вы не хотите иметь в своем коде.