Kursun məzmunu
1. Giriş 2. Metod imzası 3. Metod gövdəsi 4. Metodun həddən artıq yüklənməsi 5. Metodun əsas götürülməsi 6. İnlining 7. Rekursiya 8. Metod istinadları 9. Dəyişməzlik 10. Metod sənədləri 11. Metod parametrləri və qaytarılan dəyərlər 12. Metod Əlavə 13-ə giriş nöqtəsi. Növbəti nə var 14. Mənbə kodunun yüklənməsi1. Giriş
Təlimin bu hissəsində biz Java-da metodların layihələndirilməsi və tətbiqi ilə bağlı müxtəlif aspektləri müzakirə etməyə bir qədər vaxt sərf edəcəyik. Təlimin əvvəlki hissəsində Java-da yazma üsullarının çox asan olduğunu görə bilərsiniz, lakin metodlarınızı daha oxunaqlı və səmərəli edə biləcək bir çox şey var.2. Metod imzaları
Artıq bildiyiniz kimi, Java obyekt yönümlü bir dildir. Əslində, hər bir Java metodu sinfin hansısa hissəsinə (və ya statistik metodda sinfin özünə) aiddir. Onun görünmə (və ya əlçatanlıq) qaydaları var, mücərrəd və ya yekun elan edilə bilər və s. Bununla belə, bəlkə də metodun ən vacib hissəsi onun imzasıdır: qaytarma növü və arqumentləri, üstəlik, hər bir metodun həyata keçirilə biləcəyi yoxlanılan istisnaların siyahısı (lakin bu hissə keçmişdə tez-tez istifadə edilmirdi və bu günlərdə daha az istifadə olunurdu). ). Kiçik bir nümunə ilə başlayaq.1 public static void main( String[] args ) { 2 // Some implementation here 3 } Əsas metod bir sıra sətirləri yalnız args arqumenti kimi götürür və heç nə qaytarmır. Bütün üsulları əsas kimi sadə etmək çox gözəl olardı. Amma reallıqda metod imzası oxunmaz ola bilər. Gəlin aşağıdakı misala baxaq: 1 public void setTitleVisible( int lenght, String title, boolean visible ) { 2 // Some implementation here 3 } Burada diqqət yetirdiyiniz ilk şey, konvensiyaların setTitleVisible kimi Java metod adlarında yerli olaraq istifadə edilməsidir.Ad yaxşı seçilmişdir və metodun nə etməli olduğunu təsvir etməyə çalışır. İkincisi, arqumentlərin adları onların məqsədinin nə olduğunu bildirir (və ya heç olmasa işarə edir). Metod arqumentləri üçün int i, String s, boolean f əvəzinə düzgün, mənalı adlar tapmaq çox vacibdir (çox nadir hallarda bu məna verir). Üçüncüsü, metodun yalnız üç arqumenti var. Java-da icazə verilən arqumentlərin sayı ilə bağlı daha yüksək həddi olsa da, 6-dan çox arqumentlərin sayını keçməmək qətiyyətlə tövsiyə olunur. Bu limitdən kənara çıxmaq imzanın başa düşülməsini çətinləşdirir. Java 5 buraxıldığından, metodlar eyni tipli (varargs adlanır) müxtəlif arqumentlər siyahılarına malik ola bilər və xüsusi sintaksisdən istifadə edə bilər, məsələn: 1 public void find( String … elements ) { 2 // Some implementation here 3 } Daxili olaraq, Java tərtibçisi dəyişən arqumentləri uyğun tiplər massivinə çevirir və beləliklə, dəyişən arqumentlər ola bilər. üsulu həyata keçirmək üçün qəbul edilmişdir. Maraqlıdır ki, Java həm də ümumi parametrlərdən istifadə edərək vararqları elan etməyə imkan verir. Bununla belə, arqumentin növü naməlum olduğundan, Java tərtibçisi varargların düzgün istifadə edildiyinə əmin olmaq istəyir və son üsulları @SafeVarargs ilə qeyd etməyi tövsiyə edir (ətraflı məlumat üçün təlimatın 5-ci hissəsinə baxın, Necə və nə vaxt istifadə etmək olar Sadalamalar və Annotasiyalar). Sadalamalar və Şərhlərdən istifadə edirik) Məsələn:1 @SafeVarargs 2 final public< T > void find( T ... elements ) { 3 // Some implementation here 4 } Другой ближайший путь это использовать @SuppressWarnings комментарии, например
1 @SuppressWarnings( "unchecked" ) 2 public< T > void findSuppressed( T ... elements ) { 3 // Some implementation here 4 } Следующий пример демонстрирует использование проверки исключений How части сигнатуры метода. В недалеком прошлом проверка исключений показала себя не настолько полезной, Howой она предполагалась быть, в результате шаблонный code был использован скорее для записи, чем для решения проблем.
1 public void write( File file ) throws IOException { 2 // Some implementation here 3 } Последнее, но, тем не менее, важное, How правило, рекомендуется (но редко используется), отметить аргументы метода, How final. Это поможет избавиться от практики написания плохого codeа, когда аргументы метода предназначены различным значениям. Кроме того, такие аргументы метода могут быть использованы анонимными классами (подробнее об анонимных классов рассматривается в части 3 учебника, , How to design Classes and Interfaces (Как проектировать Классы и Интерфейсы)), хотя Java 8 облегчила немного это ограничение путем введения эффективных final переменных.
3. Тело метода
Каждый метод имеет свою реализацию и цель существования. Однако, имеется пара общих рекомендаций которые реально помогают написанию ясных и понятных методов. Вероятно, наиболее важный принцип - это принцип единичной ответственности: нужно пытаться реализовать метод таким путем, чтобы каждый единичный метод делал что-то одно, и делал это хорошо. Следуя этому принципу возможно раздувание количества методов класса, и важно найти правильный баланс. Другая важная вещь в процессе codeирования и проектирования - это делать реализуемые методы короткими. Для коротких методов легко понять причину, по которой они сделаны, плюс они обычно умещаются на экран, и таким образом могут быть очень быстро поняты читателем вашего codeа. Последний по порядку (но не по значению) совет связан с использованием return операторов. Если метод возвращает некоторое meaning, пытайтесь минимизировать число мест, где return meaning было бы вызвано (некоторые люди идут даже дальше и рекомендуют использовать лишь единичное return meaning во всех случаях. Чем больше return значений имеет метод, тем более тяжело становится следовать его логике и модифицировать (or оптимизировать) реализацию.4. Перегрузка метода
Техника перегрузки методов часто используется, чтобы обеспечить специализацию версий метода для различных типов аргументов or их комбинаций. Хотя Name метода одинаковое компьютер выбирает правильную альтернативу, углубляясь в текущие значения аргументов в точке вызова (лучший пример перегрузки это конструкторы Java: Name всегда одинаковое, но аргументы разные) or вызывает ошибку компилятора, если такой вариант метода не найден. Например:1 public String numberToString( Long number ) { 2 return Long.toString( number ); 3 } 4 5 public String numberToString( BigDecimal number ) { 6 return number.toString(); 7 } Перегрузка метода отчасти близка к дженерикам (больше информации о дженериках можно найти в части 4 учебника How and when to use Generics (Как и когда использовать дженерики)), однако перегрузка используется в случае, где подход с использованием дженериков не работает хорошо и каждый or большинство типов аргументов, которые являются дженериками, требуют своих собственных специализированных реализаций. Тем не менее, комбинируя оба способа дженерики и перегрузку можно быть очень производительным, но часто это невозможно в Java, потому что тип стирается (больше информации в части 4 учебника How and when to use Generics (Как и когда использовать дженерики)). Давайте взглянем на пример:
1 public< T extends Number > String numberToString( T number ) { 2 return number.toString(); 3 } 4 5 public String numberToString( BigDecimal number ) { 6 return number.toPlainString(); 7 } Хотя этот кусок codeа мог быть написан без использования дженериков, это неважно для наших демонстрационных целей. Интересно, что метод numberToString перегружен специальной реализацией BigDecimal и version на дженериках предназначена для всех остальных чисел.
5. Переопределение метода
Мы много говорor о переопределении методов в части 3 учебника (How to design Classes and Interfaces (Как проектировать классы и интерфейсы). В этом разделе, когда мы уже знаем о перегрузке методов, мы собираемся показать, почему использование @Override аннотации так важно. Наш пример продемонстрирует тонкое различие между переопределением метода и перегрузкой метода в простой иерархии классов.1 public class Parent { 2 public Object toObject( Number number ) { 3 return number.toString(); 4 } 5 } Родительский класс имеет только один метод toObject. Давайте создадим подкласс этого класса и попытаемся придумать версию метода преобразования чисел в строки (instead of необработанных an objectов).
1 public class Child extends Parent { 2 @Override 3 public String toObject( Number number ) { 4 return number.toString(); 5 } 6 } Тем не менее, сигнатура метода toObject в дочернем классе немногим отличается (см Covariant method return types (Ковариантные типы возвращаемые методами) для более подробной информации), и это делает переопределение его из суперкласса в свой класс, при этом компилятор Java не выдает ниHowих ошибок и предупреждений. Теперь, давайте добавим еще один метод к дочернему классу.
1 public class Child extends Parent { 2 public String toObject( Double number ) { 3 return number.toString(); 4 } 5 } Опять же, есть только небольшая разница в сигнатуре метода (Double instead of Number), но то, что в данном случае это перегруженная version метода, не отменяет переопределения метода родителя. То есть, когда подсказка от компилятора Java и @Override аннотации перекрываются: метод с аннотацией из последнего примера с @Override вызовет ошибку компилятора.
6. Встраивание
Встраивание - это оптимизация, осуществляемая с помощью Java JIT (точно в срок) компилятора для того, чтобы устранить конкретный вызов метода и заменить его непосредственно реализацией метода. Использование компилятора JIT эвристики зависит от двух вещей - How часто метод вызывается в настоящее время, а также от того, насколько он большой. Методы, которые слишком велики, не могут быть эффективно встроены. Встраивание может обеспечить значительный прирост производительности codeа и преимущество хранения методов короткими, How мы уже обсуждали в разделе Method body (Тело метода).7. Рекурсия
Рекурсия в Java - это техника, где метод вызывает сам себя, выполняя расчеты. Например, давайте взглянем на следующий пример, который суммирует число массива:1 public int sum( int[] numbers ) { 2 if( numbers.length == 0 ) { 3 return 0; 4 } if( numbers.length == 1 ) { 5 return numbers[ 0 ]; 6 } else { 7 return numbers[ 0 ] + sum( Arrays.copyOfRange( numbers, 1, numbers.length ) ); 8 } 9 } Это очень неэффективная реализация, однако она демонстрирует рекурсию достаточно хорошо. Существует одна хорошо известная проблема с рекурсивными методами: в зависимости, насколько глубока цепь вызовов, они могут переполнить стек и вызвать исключение StackOverflowError. Но не все так плохо, How кажется, потому что есть техника, которая может устранить переполнение стека, называемая tail call optimization (оптимизация хвоста вызова). Она может быть применена, если метод с хвостовой рекурсией (методы с хвостовой рекурсией это методы, в которых все рекурсивные вызовы это хвостовые вызовы). Например, давайте перепишем предыдущий алгоритм с использованием в хвостовой рекурсии:
01 public int sum( int initial, int[] numbers ) { 02 if( numbers.length == 0 ) { 03 return initial; 04 } if( numbers.length == 1 ) { 05 return initial + numbers[ 0 ]; 06 } else { 07 return sum( initial + numbers[ 0 ], 08 Arrays.copyOfRange( numbers, 1, numbers.length ) ); 09 } 10 } К сожалению, на данный момент компилятор Java (а также компилятор JVM JIT) не поддерживает tail call optimization хвостовую оптимизация, но все-таки это очень полезная техника, и ее надо знать и принимать во внимание, когда вы пишете рекурсивные алгоритмы в Java.
8. Ссылки методов
В Java 8 сделан огромный шаг вперед, путем введения функциональных понятий в язык Java. Основание, которое трактует методы How данные, понятие, которое не поддерживалось в языке до этого (однако, с тех пор How выпущена Java 7, JVM и стандартная библиотека Java уже были некоторые наработки, чтобы сделать это возможным). К счастью, имея ссылки методов, теперь это возможно. Ссылка статического метода: SomeClass::staticMethodName Ссылка на метод экземпляра конкретного an object: someInstance::instanceMethodName Ссылка на метод экземпляра произвольного an object определенного типа: SomeType::methodName Ссылка на конструктор: SomeClass::new Давайте взглянем на небольшой пример того, How методы могут быть использованы в качестве аргументов других методов.01 public class MethodReference { 02 public static void println( String s ) { 03 System.out.println( s ); 04 } 05 06 public static void main( String[] args ) { 07 final Collection< String > strings = Arrays.asList( "s1", "s2", "s3" ); 08 strings.stream().forEach( MethodReference::println ); 09 } 10 } В последней строке main метод использует ссылку на println метод чтобы напечатать каждый элемент из коллекции строк в консоль, он передается в качестве аргумента другому методу, forEach.
9. Неизменность
Неизменность обращает на себя много внимания в эти дни, и Java не является исключением. Хорошо известно, что неизменности трудно добиться в Java, но это не значит, что это должно быть проигнорировано. В Java, неизменность - это все знания об изменении внутреннего состояния. В качестве примера, давайте взглянем на спецификации JavaBeans (http://docs.oracle.com/javase/tutorial/javabeans/). В ней говорится, очень ясно, что сеттеры могут изменить состояние an object, что- то до этого содержащего, и это то, что ожидает каждый разработчик Java. Тем не менее, альтернативный подход мог бы не менять состояние, а возвращать новый an object (new) каждый раз. Это не так страшно, How кажется, и новый Java 8 Date/Time API ( разработан под JSR 310: Date and Time API прикрытием) является отличным примером этого. Давайте взглянем на следующий фрагмент codeа:1 final LocalDateTime now = LocalDateTime.now(); 2 final LocalDateTime tomorrow = now.plusHours( 24 ); 3 4 final LocalDateTime midnight = now 5 .withHour( 0 ) 6 .withMinute( 0 ) 7 .withSecond( 0 ) 8 .withNano( 0 ); Каждый вызов LocalDateTime an object, который должен изменить свое состояние возвращает новый экземпляр LocalDateTime, и держит оригинал без изменений. Это большой сдвиг в парадигме дизайна API по сравнению с старыми Calendar и Date, (которые, мягко говоря, были не очень приятны в использовании и вызвали много головной боли).
10. Документирование метода
В Java, в частности, если вы разрабатываете Howую-то библиотеку or framework, все публичные методы должны быть заdocumentированы с помощью инструмента Javadoc (http://www.oracle.com/technetwork/articles/java/index-jsp-135444.html). Строго говоря, ничего не заставляет вас делать это, но хорошая documentация помогает другим разработчикам понять, что конкретный метод делает, Howие аргументы он требует, Howовы предположения or ограничения его реализации, Howие типы исключений он вызывает и когда они возникают, Howое может быть возвращаемое meaning (если таковые имеются), а также многие другие вещи. Давайте взглянем на следующий пример:01 /** 02 * The method parses the string argument as a signed decimal integer. 03 * The characters in the string must all be decimal digits, except 04 * that the first character may be a minus sign {@code '-'} or plus 05 * sign {@code '+'}. 06 * 07 *
An exception of type {@code NumberFormatException} is thrown if 08 * string is {@code null} or has length of zero. 09 * 10 *
Examples: 11 *
12 * parse( "0" ) returns 0
13 * parse( "+42") returns 42
14 * parse( "-2" ) returns -2
15 * parse( "string" ) throws a NumberFormatException
16 *
17 * 18 * @param str a {@code String} containing the {@code int} representation to be parsed 19 * @return the integer value represented by the string 20 * @exception NumberFormatException if the string does not contain a valid integer value 21 */ 22 public int parse( String str ) throws NumberFormatException { 23 return Integer.parseInt( str ); 24 } Это довольно многословная documentация для такого простого метода How parse, но это показывает пару полезных возможностей обеспечиваемых инструментом Javadoc tool, в том числе ссылки на другие классы, образцы фрагментов и продвинутого форматирования. Вот How этот documentация методов отражается в Eclipse, одной из популярных Java IDE. Просто глядя на изображение выше, любой разработчик Java от младшего до старшего уровня может понять цель метода и надлежащим образом использовать ее.
11. Параметры метода и возвращаемые значения
Документирование ваших методов - это великая вещь, но, к сожалению, это не предупреждает случаи, когда метод называют, используя неправильные or неожиданные значения аргументов. Из-за этого, How правило, все публичные методы должны подтвердить свои аргументы и никогда не должны быть уверены, что все время при вызове будут указаны правильные значения (паттерн более известный How sanity checks (санитарная проверка)). Возвращаясь к нашему примеру из предыдущего раздела, метод parse должен выполнить проверку своего единственного аргумента, прежде чем делать что-нибудь с ним:1 public int parse( String str ) throws NumberFormatException { 2 if( str == null ) { 3 throw new IllegalArgumentException( "String should not be null" ); 4 } 5 6 return Integer.parseInt( str ); 7 } Java имеет другой вариант выполнения проверки и sanity checks, используя assert операторы. Однако, те, которые могли быть выключены во время выполнения и могут быть не выполнены. Предпочтительно, всегда выполнять такие проверки и вызывать соответствующие исключения. Даже имея documentированные методы и проверку их аргументов, хочу сделать еще пару замечаний связанных с возвращаемыми значениями. До того How вышла Java 8, самым простым способом сказать что метод в данное время не имеет значения чтобы его возвратить было просто вернуть нуль. Вот почему Java так плохо получить исключение NullPointerException. Java 8 пытается решить этот вопрос с введением Optional < T > class. Давайте взглянем на этот пример:
1 public< T > Optional< T > find( String id ) { 2 // Some implementation here 3 } Optional < T > предоставляет много полезных методов, и fully устраняет необходимость возвращать в методе null и загрязнять везде ваш code проверками на null. Единственное исключение, вероятно, это коллекции. Всякий раз, когда метод возвращает коллекцию, всегда лучше вернуть null instead of null (и даже Optional < T >), например:
1 public< T > Collection< T > find( String id ) { 2 return Collections.emptyList(); 3 }
12. Метод How точка входа в приложение
Təşkilatınızda proqramlar yazan sadə bir tərtibatçı olsanız və ya ən populyar Java çərçivələrindən və ya kitabxanalarından birinə töhfə verən olsanız belə, verdiyiniz dizayn qərarları kodunuzun necə istifadə olunacağında çox mühüm rol oynayır. API dizayn qaydaları bir neçə kitaba dəyər olsa da, dərsliyin bu hissəsi onların bir çoxunu əhatə edir (metodlar API-yə necə giriş nöqtəsi olur), ona görə də qısa icmal çox faydalı olacaq: • Metodlar və onların arqumentləri üçün mənalı adlardan istifadə edin (Metod İmzalar ) Arqumentlərin sayını 6-dan az saxlamağa çalışın (Metod imzaları bölməsi) • Metodlarınızı qısa və oxunaqlı saxlayın (Metodun əsas hissəsi və Inlining bölməsi) • Məntiqli olarsa, ilkin şərtlər və nümunələr daxil olmaqla həmişə açıq metodları sənədləşdirin (bölmə Metod Sənədləşdirmə) • Həmişə arqument yoxlanışı və sağlam düşüncə yoxlanışı aparın (Metod Parametrləri və Qaytarma Dəyərləri bölməsi) • Qayıdış dəyərləri kimi nulldan qaçmağa çalışın (Metod Parametrləri və Qaytarma Dəyərləri bölməsi) • Məntiqli olduqda, dəyişməz metodlar tərtib etməyə çalışın (bunlar daxili vəziyyətə təsir etmir, Dəyişməzlik bölməsi) • İctimai olmayan metodları gizlətmək üçün görünmə və əlçatanlıq qaydalarından istifadə edin (təlimatın 3-cü hissəsi, Sinifləri və İnterfeysləri necə tərtib etmək olar)13. Növbəti nə var
Təlimin bu hissəsində bir dil olaraq Java haqqında bir az daha az danışılır və Java dilindən necə səmərəli istifadə etmək, xüsusən oxunaqlı, təmiz, sənədləşdirilmiş və səmərəli metodların yazılması haqqında daha çox danışır. Növbəti bölmədə biz eyni əsas ideyanı davam etdirəcəyik və daha yaxşı Java tərtibatçısı olmağa kömək etmək üçün nəzərdə tutulmuş ümumi proqramlaşdırma prinsiplərini müzakirə edəcəyik.14. Mənbə kodunu yükləyin
Bu dərs üsulları necə effektiv yazmaq barədə idi. Mənbə kodunu buradan yükləyə bilərsiniz:
GO TO FULL VERSION