Это в порядке для записи моих собственных дополнительных методов в системном пространстве имен?
В зависимости от вашей конкретной цели существует способ достижения полезности родительского селектора без использования одного (даже если бы он существовал) ...
Скажем, у нас есть:
<div>
<ul>
<li><a>Pants</a></li>
<li><a>Socks</a></li>
<ul>
<li><a>White socks</a></li>
<li><a>Blue socks</a></li>
</ul>
</ul>
</div>
Что мы можем сделать, чтобы блок Socks (включая цвета носка) выделялся визуально с использованием интервала?
Что было бы неплохо, но не существует:
ul li ul:parent {
margin-top: 15px;
margin-bottom: 15px;
}
Что существует:
li > a {
margin-top: 15px;
display: block;
}
li > a:only-child {
margin-top: 0px;
}
Это устанавливает, что все привязные ссылки имеют верхний край 15px и сбрасывают его обратно на 0 для тех, у которых нет элементов UL (или других тегов) внутри LI.
5 ответов
Из Руководства по проектированию Платформы (2-й Выпуск):
НЕ помещают дополнительные методы в то же пространство имен как расширенный тип, если это не для добавления методов к интерфейсам, или для управления зависимостью.
, В то время как это явно не покрывает Ваш сценарий, необходимо обычно стараться не расширять пространство имен Платформы (или любое пространство имен, Вы не имеете никакого контроля), и решите вместо этого поместить те расширения в их собственное пространство имен. Если Вы чувствуете сильно о "группировке" расширений (таким образом, что расширения набора вместе, и т.д.), тогда, Вы могли представить подпространство имен. В Вашем сценарии расширение наборов вошло бы System.Collection.Extensions пространство имен или Company.Collections или даже Company.Collections.Extension пространство имен.
для использования дополнительных методов пространство имен, содержащее класс спонсора (класс, который определяет дополнительные методы) должен быть импортирован. Если Вы добавите дополнительные методы к одному из стандартных пространств имен Платформы.NET, то они всегда будут (и неявно) доступны.
Необходимо постараться не увеличивать пространства имен, над которыми Вы не имеете основного контроля, поскольку будущие изменения могут повредить Ваш код (путем представления дубликатов, например).
я склонен подражать стандартным пространствам имен с различным корневым пространством имен, которое идентифицирует все дочерние пространства имен как принадлежащий моей работе. Корневое пространство имен могло быть Вашим именем, названием Вашей организации или чем-то еще, что определяет содержание того пространства имен, как являющегося Вашим.
, Например, если Вы хотите расшириться System.Collections, Вы могли бы использовать NickR.Collections или NickR.System.Collections.
Единственной вещью, на которую пространство имен действительно влияет с дополнительными методами, является видимость и discoverability - таким образом, это зависит от того, хотите ли Вы, чтобы дополнительные методы всегда появились на том типе или нет. Руководство по проектированию платформы предназначается, прежде всего, для общедоступных API и так, в то время как это обычно - хорошая идея следовать за ними, правила очень там, чтобы быть поврежденными для внутренних API, когда это имеет смысл.
, Например, мы делаем большую работу с TimeSpan объекты всюду по кодовой базе и нет никаких методов, чтобы умножить или разделить их на платформу, таким образом, мы добавили MultiplyBy и DivideBy дополнительные методы, среди других, и поместили их в System пространство имен, потому что мы хотим их доступный и поддающийся обнаружению везде, где TimeSpan используется.
, С другой стороны, мы также делаем довольно мало отражательной работы, воздействующей на Type объекты, и существует много дополнительных методов, которые очень полезны в определенных областях, но не обычно, таким образом, они живут в OurCompany.Reflection пространство имен, таким образом, они должны быть конкретно импортированы.
Так для внутренних API решение сводится, чтобы "сделать, я хочу, чтобы этот метод был доступен везде, тип доступен в нашей кодовой базе?". Если ответ да, то помещенный это в то же пространство имен, иначе помещает его где-то в другом месте.
Не уверенный, если это неправильно (или право, в этом отношении), но почему бы не Ваше собственное пространство имен 'Расширений'? Тогда поместите все свои дополнительные методы в то пространство имен и будьте последовательны об этом.
я не думаю, что настоящая проблема состоит в том, куда поместить их или что назвать ее (система или любое другое пространство имен), но быть последовательной и всегда использовать то же для предотвращения проблемы (упущение, где они).
Я поместил свои методы расширения в пространство имен в зависимости от видимости, которую я хочу, чтобы они имели. Тем путем их легче обнаружить, и я обычно получаю меньше импорта пространства имен.