Насколько важен контекст, который подразумевается под пространством имен?

Question

Хорошо, название может звучать немного расплывчато, но я действительно не могу придумать что-то более ясное здесь.

Недавно я был в положении, когда мне был нужен класс Point, просто с двумя свойствами, X и Y и ctor Point(int x, int y). Ничего фантастического. Теперь эта вещь уже существует в .NET, но это было в библиотеке, которая обрабатывает определенные объекты на карте и перетаскивает System.Drawing в это только что чувствовалось ... как-то неправильно Несмотря на то, что System.Drawing.Point идеально соответствует тому, что мне нужно, я теперь снова создал эту структуру в этом проекте.

Теперь мне интересно, было ли это правильно или разумно делать. System.Drawing.Point пришел бы и со ссылкой на эту сборку, если я правильно помню. А поместить что-то в System.Drawing в совершенно не связанный с рисованием контекст было как-то странно.

Мысли? Что если бы не подразумевалась ссылка на другую сборку?

Answer 1

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

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

Возможно,особенно это приводит к проблемам при развертывании более новой версии сборки, которая больше не совместима с тем, как вы ее используете, или более новая версия приносит дополнительные элементы и зависимости, которые вы не хотите иметь в своем коде.

Answer 2

Контекст пространства имен имеет фундаментальное значение для приближения к точной функции класса;класс Connection будет очень отличаться от одного пространства имен к другому.Будет ли класс Web.Cache пригоден для кэширования в других приложениях или он имеет фундаментальную зависимость от веб-инфраструктуры?

MSDN описывает структуру System.Drawing.Point следующим образом:

«Представляет упорядоченную пару целочисленных x- и y-координат, определяющих точку в двумерной плоскости.»

При таком общем описании можно утверждать, что эта структура является толькослучайно относится к рисованию и действительно принадлежит к более фундаментальному пространству имен.

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

Answer 3

Я недавно был в похожей ситуации.Класс Point не нужен, но я буду использовать его в качестве примера.

Я создал собственный класс Point, потому что System.Drawing.Point использует целочисленные значения, когда мне нужно удваивается.Позже я понял, что это хорошая идея, даже если мне нужны только целые числа, потому что я могу расширять класс по мере необходимости, добавлять методы, интерфейсы, атрибуты и т. Д. В то время как я не смог бы, если бы использовал Систему.Drawing.Point.

Существует принцип, согласно которому вы не должны дублировать знания в своих программах, но в некоторых случаях, таких как этот, этого не избежать.

---

Какдля ссылки на другую сборку вы можете сделать это:

using Point = System.Drawing.Point;  // or whatever your namespace is called

Answer 4

Если ваша цель не связана с рисованием, я думаю, вы поступили правильно. Использование System.Drawing.Point в коде, который вообще не связан с рисованием, может сбить людей с толку и подумать, что они используются для некоторых функций рисования.

Answer 5

Я бы не сказал, что то, что вы сделали, было неправильно, однако пространство имен на самом деле является просто контейнером для объявлений, в которых каждое имя уникально, имя пространства имен действительно предоставляет некоторый контекст, который поможет вам найти нужную функцию для ваших нужд, но нене зацикливайтесь на контексте, не совсем подходящем для вашего использования, если объект идеален, то он идеален.Помимо оператора using вы, вероятно, никогда больше не будете активно ссылаться на пространство имен.

Answer 6

Я бы очень мало беспокоился о том, чтобы внести что-то из пространства имен, учитывая, что как функционально, так и концептуально (как это описано в документации) это соответствует цели.

Я мог бы не захотеть ввести новую сборкухоть.В этом случае тот факт, что Point так быстро сворачивает свои собственные, что я мог бы подумать о том, чтобы делать это меньше, чем добавлять другую зависимость к сборке, которую я писал.

В противном случае, пока я не былне использовать его в качестве ключа (значение GetHashCode, входящее в точку, не очень хорошо в том смысле, как оно сталкивается, например, со всеми {0,1}, {1,0}, {2,3} и {3,2}если у вас много малоценных или прямоугольных распределенных точек), я бы использовал их.

Answer 7

Если вы не импортируете какой-либо «багаж» (например, нужно инициализировать вещи, которые вы не используете), так что это именно то, что вам нужно, я бы пошел на существующий код. Просто нет смысла воссоздавать существующий код. Также есть вероятность, что позже вы сможете обнаружить функции, которые выполняют нужные вам функции, и ожидаете этого конкретного класса.

Тем не менее, я могу отождествить себя со странным ощущением наличия в вашем коде "чужого" объекта. Один из способов обойти это - создать подкласс с вашей собственной точкой зрения. Это будет выглядеть немного странно, если вы ничего не меняете в своем подклассе, но это видно только в исходном коде этого класса, и там, где вы его используете, он постоянно именуется. Кроме того, он начнет выглядеть действительно умным, как только вы добавите функциональность к своей пользовательской точке.

Answer 8

Я бы просто использовал System.Drawing.Point. Зачем заново создавать то, что уже существует? Кому интересно, как называется пространство имен, если обеспечивает необходимую вам функциональность. Только мои 2 цента ...