Вы действительно используете свой обратный домен для именования пакета в Java? [закрытый]
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
9 ответов
Как только Вы понимаете, почему соглашение существует, это не должно чувствовать себя глупым или неловким ни в малейшей степени.
Эта схема делает две важных вещи:
-
Весь Ваш код содержится в пакетах, с которыми никто еще не столкнется. Вы владеете своим доменным именем, таким образом, оно изолируется. Если бы у нас не было этого соглашения, многие компании имели бы пакет "утилит", содержа классы как "StringUtil", "MessageUtil" и т.д. Они быстро столкнулись бы, если бы Вы пытались использовать чей-либо еще код.
-
"обратная" природа его делает расположение каталога класса очень узким на верхнем уровне. При расширении банки Вы будете видеть "com", "org", "сеть" и т.д. директора, то под каждым из тех организация/название компании.
Мы обычно не разворачиваем банки, но в ранней разработке Java, это было важно, потому что люди использовали расширенные структуры dir для апплетов.
Однако это хорошо теперь, поскольку структуры dir исходного кода имеют "очень нисходящее" чувство. Вы идете от самого общего (com, org, сеть...) к менее общему (название компании) к более определенному (название проекта/продукта/lib)
Я на самом деле думаю, что обратное именование пакета доменного имени является одним из более блестящих соглашений в Java.
Если бы это - просто внутренний проект, и код вряд ли будет когда-либо снова использоваться, то я обычно шел бы с короткими, описательными именами.
Однако, если код должен использоваться внешне или снова использоваться в другом проекте, то я склонен идти с обратной доменной схемой. Это удостоверяется, что не будет никаких столкновений имени пакета.
Я думаю, что это зависит значительно от того, какое программное обеспечение пишется. Например, я разрабатываю внутренние системы для небольшой компании, таким образом, я выбираю:
[company].[project].[sub].xyz(.abc)
, Где sub обычно один из client, common и server. Если бы я работал в (коммерческой) компании-разработчике программного обеспечения, я намного более отказался бы использовать эти project бит, потому что вероятно, что, чем назвали приложение, когда запущенный проект и чем это называют, когда это закончилось, две абсолютно отдельных вещи! Вот к:
oak.lang.Object
Я нахожу его довольно глупым сам. Com. часть действительно добавляет только 4 дополнительных символа. Кроме того, я думаю с помощью названия компании в блоке / название проекта является также неправильным. Я работал в слишком многих местах, которые объединились с другой компанией или просто переименовали себя.
Я делаю это для всех своих проектов, я даже взял его через к моим приложениям.NET для пространств имен.
Да, я даже разработал схему создать пространства имен в JavaScript с помощью обратного доменного соглашения о присвоении имен, он делает находящие определенные активы и что они ответственны за намного более легкий, и он помогает предотвратить коллизии имени.
Да, я использую обратный домен для запуск пакета, сопровождаемого другой административной информацией (проекты, отделы, и т.д.). Использование домена сводит к минимуму вероятность коллизий между vendors/companies/FOSS проектами. Мой пакет "данных" не столкнется с блоком данных другой компании благодаря домену.
я также использовал соглашение отбрасывания tld для внутренней работы или классов, которые не предназначены для внешнего использования (возможно, недокументированные вспомогательные библиотеки, и т.д.). Это обычно проясняет другим разработчикам, что различные правила или политики могут относиться к блоку кода.
Используя обратный домен намного менее хаотично, чем произвольные пространства имен, которые не следуют никаким правилам или установленному шаблону.
Это очень полезно и скопировано другими (например, XML-схема).
Это полезно в 'большом' (учитывая WWW), но возможно больше через отделы (т.е. в маленьком). Это может казаться чрезмерно увеличенным в размерах для меньших проектов, но это действует как страховка: это там при необходимости в нем позже.