Лучшие практики для создания библиотек та.NET использования пространства имен
Это - плохая практика для записи библиотеки, которая определяет интерфейс, зависящий от другой библиотеки?
Я знаю, что плотное соединение плохо, но это все еще применяется при использовании классов.NET?
Например, в.NET, если у меня есть библиотека, которая возвращает Цветовой объект, он вызвал бы зависимость от Системы. Привлечение чего-либо, что пользуется моей библиотекой. Я был бы более обеспеченным созданием моего собственного класса Типа цвета в моей библиотеке?
6 ответов
Я различаю Неустойчивые и Стабильные зависимости .
В общем, Color выглядит как стабильная зависимость, потому что он уже находится в BCL, он детерминирован по своей природе и не требует каких-либо ресурсоемких выходов - взаимодействия процессов, и при этом он не полагается на конкретную настройку своей среды выполнения.
Единственное соображение здесь состоит в том, что когда дело доходит до Color, в BCL существует более одного такого класса,
Если это стандартная библиотека .NET, я бы не стал об этом беспокоиться. Нет причин для сопоставления одного класса с другим ... что, если System.Color изменится в следующем выпуске .NET? Вам также придется изменить свой код сопоставления и, возможно, придется определить версию и сопоставить соответственно. Это настоящая боль.
Со всеми своими библиотеками я возвращаю объекты, которые зависят только от вещей в библиотеке.
Я бы спросил себя, почему я писал библиотеку, которая будет зависеть от другого пространства имен, которое не было неявный. Кажется, это идет вразрез со всей концепцией "инкапсуляции".
Так что, просто исходя из моих собственных рассуждений и знаний ООП, я бы сказал, что вы на правильном пути, возвращая свой собственный независимый объект.
Вы задаете отличный вопрос. Ответ: это зависит от обстоятельств. В случае стандартных библиотек, которые всегда будут доступны, это нормально; основная библиотека все время ссылается на разные .DLL.
В случае использования сторонней библиотеки вы столкнетесь с проблемами. Не всегда рекомендуется использовать собственную библиотеку, если что-то еще делает то, что вы хотите, но тогда у вас есть зависимость от другой библиотеки, что является логистической проблемой для пользователей.
Здесь нет правильного ответа, вам просто нужно выбрать то, что имеет наибольший смысл для вашего проекта. Постарайтесь как можно больше развязаться, да, но иногда вам просто нужно прижаться друг к другу и выполнить свою работу.
Это зависит от вашего использования класса.
Если вам когда-нибудь понадобится получить экземпляр системного класса Color из экземпляра вашего класса Color (например, если вы рисуете в windows form), то было бы лучше использовать класс System - он избавляет вас от необходимости преобразования между двумя типами и дает вам преимущество, заключающееся в том, что вы можете использовать все «функции» класса Color бесплатно (например, как встроенные константы для «Красный», «Черный», «Зеленый» и т. д.
Если, с другой стороны, вы просто работаете с произвольными значениями RGB (возможно, для научных расчетов) и никогда необходимо преобразовать в экземпляр System.Color, тогда может иметь смысл создать свой собственный класс.
По всей вероятности, вам лучше использовать System.Цветовой класс - да, инкапсуляция и все это - хорошая идея, но не за счет экономии вашего времени!
Нельзя беспокоиться об использовании чего-либо из основной библиотеки .NET. Без него вы бы не продвинулись далеко в написании DLL. Единственное место, где можно быть осторожным с этим, - это пространство имен System.Web, поскольку я считаю, что в .NET 4 есть установщик профиля клиента, что в основном означает, что если вы используете этот установщик, он будет устанавливать только то, что предполагается использовать на клиенте. Я лично считаю, что со стороны Microsoft это плохая идея, поскольку она просто добавляет ненужные сложности для экономии небольшого количества времени загрузки.