Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
При выборе имен придерживайтесь общепринятых соглашений
Платформа Java обладает хорошо устоявшимся набором соглашений, касающихся выбора имен (naming convention). Многие из них приведены в "The J а v а Lа n gиаgе Sресi f i:аtiоп" [JLS, 6.8]. Соглашения об именовании делятся на две ка-r:егории: типографские и грамматические. Типографских соглашений, касающихся выбора имен для пакетов, классов, интерфейсов и полей, очень мало. Никогда не нарушайте их, не имея на то веской причины. API, не соблюдающий эти соглашения, будет трудно использовать. Если соглашения нарушены в реализации, ее будет сложно сопровождать. В обоих случаях нарушение соглашений может запутывать и раздражать других программистов, работающих с этим кодом, а также способствовать появлению ложных допущений, приводящих к ошибкам. Названия пакетов должны представлять собой иерархию, отдельные части которой отделены друг от друга точкой. Эти части должны состоять из строчных букв и изредка цифр. Название любого пакета, который будет использоваться за пределами организации, обязано начинаться с доменного имени вашей организации в Интернете, которому предшествуют домены верхнего уровня, например edu. cmu, com.sun, gov.nsa. Исключение из этого правила составляют стандартные библиотеки, а также необязательные пакеты, чьи названия начинаются со слов jаvа и jаvах. Пользователи не должны создавать пакетов с именами, начинающимися с jаvа или jаvах. Детальное описание правил, касающихся преобразования названий доменов Интернета в префиксы названий пакетов, можно найти в "The J а v а La n gиage Sресi f саtiоп" [JLS, 7.7]. Вторая половина в названии пакета должна состоять из одной или нескольких частей, описывающих этот пакет. Части должны быть короткими, обычно не длиннее восьми символов. Поощряются выразительные сокращения, например util вместо utilities. Допустимы акронимы, например awt. Такие части, как правило, должны состоять из одного единственного слова или сокращения.
154
Многие пакеты имеют имена, в которых, помимо названия домена в Интернете, присутствует только одно слово. Большее количество частей в имени пакета нужно лишь для больших систем, чей размер настолько велик, что требует создания неформальной иерархии. Например, в пакете jаvах.swing представлена сложная иерархия пакетов с такими названиями, как jаvах.swing.plaf.metal. Подобные пакеты часто называют подпакетами, однако это относится исключительно к области соглашений, поскольку для иерархии пакетов нет лингвистической поддержки. Названия классов и интерфейсов состоят из одного или нескольких слов, причем в каждом слове первая буква должна быть заглавной, например Тiтer или ТimerTask. Необходимо избегать аббревиатур, за исключением акронимов и нескольких общепринятых сокращений, таких как mах и min. Нет полного единодушия по поводу того, должны ли акронимы полностью писаться прописными буквами или же заглавной у них должна быть только первая буква. Хотя чаще в верхнем регистре пишется все название, есть один сильный аргумент в пользу того, чтобы заглавной была только первая буква. В последнем случае всегда ясно, где кончается одно слово и начинается другое, даже если рядом стоят несколько акронимов. Какое название класса вы предпочли бы увидеть: НTTРURL или HttpUrl ? Названия методов и полей подчиняются тем же самым типографским соглашениям, за исключением того, что первый символ в названии всегда должен быть строчным, например remove, ensureCapacity. Если первым словом в названии метода или поля оказывается акроним, он весь пишется строчными буквами. Единственное исключение из предыдущего правила касается "полей-констант" (constant field), названия которых должны состоять из одного или нескольких слов, написанных заглавными буквами и отделенных друг от друга символом подчеркивания, например VALUES или NEGAТIVE_INFINIТY. Поле-константа - это поле static final, значение которого не меняется. Если поле static final имеет простой тип или неизменяемый ссылочный тип (статья 13), то это поле-константа. Даже если тип поля относится к потенциально изменяемым, это все равно может быть поле-константа при условии, что объект, на который оно ссылается, является неизменяемым. Например, перечисление типов может представить пространство своих перечислимых констант в виде неизменяемой константы типа List (статья 21). Заметим, что поля-константы единственное место, где допустимо использование символа подчеркивания. Названия локальных переменных подчиняются тем же типографским соглашениям, что и названия членов классов, за исключением того, что в них можно использовать аббревиатуры, отдельные символы, а также короткие последовательности символов, смысл которых зависит от того контекста, где эти локальные переменные находятся. Например: i, xref, houseNumber. Примеры типографских соглашений приведены в таблице 7.1. По сравнению с типографскими, грамматические соглашения, касающиеся именования, более гибкие и спорные. Для пакетов практически нет грамматических соглашений. для именования классов обычно используются существительные или именные конструкции, например Timer и BufferedWriter. Интерфейсы именуются так же,
155
как классы, например Collect1on и Comparator, либо применяются названия с окончаниями, образованными от прилагательных "-able" и "-ible", например Runnable и Accessible.
Примеры типографских соглашений
Для методов, выполняющих какое-либо действие, в качестве названия используются глаголы или глагольные конструкции, например append и drawlmage. для методов, возвращающих булево значение, обычно применяются названия, в которых сначала идет слово "is", а потом существительное, именная конструкция' или любое слово (фраза), играющее роль прилагательного, например isDigit, isPrоbаblеРrime, isEmpty, isEnabled, isRunning. Для именования методов, не связанных с булевыми операциями, а также методов, возвращающих атрибут объекта, для которого они были вызваны, обычно используется существительное, именная конструкция либо глагольная конструкция, начинающаяся с глагола "get", например size, hashCode, getТime. Отдельные пользователи требуют, чтобы применялась лишь третья группа (начинающаяся с "get"), но для подобных претензий нет никаких оснований. Первые две формы обычно делают текст программы более удобным для чтения, например:
if (car.speed() > 2* SPEED_LIMIT) generateAudibleAlert("Watch out for cops!");
Форма, начинающаяся с "get”, -обязательна, если метод принадлежит к классу Веа n [JavaBeans]. Ее можно также рекомендовать, если в будущем вы собираетесь превратить свой класс в Веаn. Наконец, серьезные основания для использования данной формы имеются в том случае, если в классе уже есть метод, присваивающий этому же атрибуту новое значение. При этом указанные методы следует назвать getAttribu t e и setAttribu t e. Несколько названий методов заслуживают особого упоминания. Методы, которые преобразуют тип объекта и возвращают независимый объект другого типа, часто называются toType, например toString, toArray. Методы, которые возвращают представление (статья 4), имеющее иной тип, чем сам объект, обычно называются asType, например asList. Методы, возвращающие простой тип с тем же значением,
156
что и у объекта, в котором они были вызваны, называются typeValue, например intValue. для статических методов генерации широко используются названия valueOf и getInstance (статья 1). Грамматические соглашения для названий полей формализованы в меньшей степени и не играют такой большой роли, как в случае с классами, интерфейсами и методами, поскольку хорошо спроектированный API, если и предоставляет какое либо поля, то немного. Поля типа boolean обычно именуются так же, как логические методы доступа, но префикс "is" у них опускается, например 1п1 tialized, composite. Поля других типов, как правило, именуются с помощью существительного или именной конструкции, например height, digits, bodyStyle. Грамматические соглашения для локальных переменных аналогичны соглашениям для полей, только их соблюдение еще менее обязательно. Подведем итоги. Изучите стандартные соглашения по именованию и доведите их использование до автоматизма. Типографские соглашения просты и практически однозначны; грамматические соглашения более сложные и свободные. Как сказано в "The J ava La n guage Speci f icatioп" [JLS, 6.8], не нужно рабски следовать этим соглашениям, если длительная практика их применения диктует иное решение. Пользуйтесь здравым смыслом.
157
Глава 8 Исключения Если исключения (exception) используются наилучшим образом, они способствуют написанию понятных, надежных и легко сопровождаемых программ. При неправильном применении результат может быть прямо противоположным. В этой главе даются рекомендации по эффективному использованию исключений. |
Последнее изменение этой страницы: 2019-04-11; Просмотров: 223; Нарушение авторского права страницы