Java 8을 위한 5가지 개발 팁

저는 몇 년 동안 새로운 애플리케이션과 기존 애플리케이션 마이그레이션을 위해 Java 8로 코딩을 해왔는데, 이제 제가 매우 유용하다고 생각하는 몇 가지 "모범 사례"에 대해 글을 쓸 때가 된 것 같았습니다. 저는 개인적으로 "모범 사례"라는 용어를 좋아하지 않습니다. 왜냐하면 이 용어는 "모든 경우에 적용되는 일률적인" 솔루션을 의미하기 때문입니다. 이는 코딩이 작동하는 방식이 아닙니다. 우리는 어떤 솔루션이 작동하는지 스스로 찾아야 합니다. 하지만 Java 8 코드에서 우리에게 도움이 될 수 있는 몇 가지 옵션을 찾았습니다. 살펴보겠습니다.

1. Optional

Optional은 심각하게 과소평가된 기능이며 우리를 괴롭히는 많은 NullPointerException을 제거할 수 있는 잠재력을 가지고 있습니다. 이는 코드 경계(사용 중인 API 또는 노출되는 API) 내에서 특히 유용합니다. 이를 통해 사용자와 호출 코드가 예상되는 내용을 추론할 수 있기 때문입니다.

그러나 생각과 디자인 없이 Optional을 적용하면 많은 클래스에 영향을 미치고 가독성이 떨어질 수 있습니다. Optional을 효과적으로 사용하는 방법에 대한 몇 가지 팁은 다음과 같습니다.

　Optional은 반환 유형에만 사용해야 합니다.

　…매개변수나 필드는 사용할 수 없습니다. 다행히 IntelliJ IDEA를 사용하면 이러한 권장 사항을 따르고 있는지 확인할 수 있습니다.



선택적 값은 만나는 곳에서 처리해야 합니다. IntelliJ IDEA의 제안은 코드에서 Optional 누출을 방지하므로 Optional을 찾은 위치에서 처리하고 신속하게 조치하는 것을 잊지 마세요.



단순히 get()을 호출하면 안 됩니다.

Optional의 기능은 값이 비어 있을 수 있음을 표현하고 이러한 상황에 대처할 수 있도록 하는 것입니다. 따라서 작업을 수행하기 전에 값이 있는지 확인하십시오. isPresent()를 먼저 확인하지 않고 단순히 get()을 호출하면 어느 시점에서 널 포인터가 발생할 수 있습니다. 다행히도 IntelliJ IDEA에는 이를 상기시켜주는 검사 기능도 있습니다.



더 우아한 방법이 있을 수도 있습니다

물론 isPresent()와 get()을 결합하면 좋을 것 같습니다...



　…하지만 더 우아한 솔루션이 있습니다. 값이 null인 경우 orElse를 사용하여 대안을 제공할 수 있습니다.



…또는 orElseGet을 사용하여 값이 비어 있는 경우 호출할 메서드를 나타낼 수 있습니다. 위의 예시와 같은 것 같지만, 공급자 메소드는 필요할 때만 호출되기 때문에 비용이 많이 드는 메소드라면 람다를 사용하는 것이 더 좋은 성능을 낼 수 있을 것이다.

2. 람다 표현식 사용하기

람다 표현식은 Java 8의 주요 기능 중 하나입니다. 아직 Java 8을 사용해 본 적이 없더라도 지금쯤이면 Java 8에 대한 기본적인 이해가 끝났을 것입니다. 이는 Java로 프로그래밍하는 새로운 방식이며 "모범 사례"가 무엇인지 아직 명확하지 않습니다. 제가 따르고 싶은 몇 가지 지침은 다음과 같습니다.

짧게 유지하세요

함수형 프로그래머는 더 긴 람다 표현식을 사용하는 것이 더 행복할 것입니다. 그러나 수년 동안 Java에 푹 빠진 사람들은 람다 표현식을 단 몇 줄의 코드로 유지하는 것이 더 쉽다는 것을 알게 될 것입니다. . 한 줄의 코드로 제한하고 더 긴 표현식을 메서드로 쉽게 리팩터링할 수도 있습니다.



　 메소드 참조가 될 수도 있습니다. 메소드 참조는 처음에는 약간 낯설게 느껴질 수도 있지만, 특정 상황에서 가독성을 높이는 데 도움이 되기 때문에 메소드 참조를 고수하는 데는 실제로 가치가 있습니다. 이에 대해서는 나중에 설명하겠습니다.



명시적

람다 표현식에는 유형 정보가 누락되어 있으므로 매개변수에 대한 유형 정보를 포함하는 것이 유용할 수 있습니다.



보시다시피 이번에는 꽤 어색해졌습니다. 그래서 저는 매개변수에 유용한 이름을 지정하는 것을 선호합니다. 물론, 이 작업을 수행했는지 여부에 관계없이 IntelliJ IDEA를 사용하면 매개변수의 유형 정보를 볼 수 있습니다.



람다로 대표되는 기능적 인터페이스까지:

3. 람다 식 설계

람다 식은 제네릭과 약간 비슷하다고 생각합니다. 제네릭과 함께 자주 사용합니다(예: 목록에 유형 정보 추가a8093152e673feb7aba1828c43532094 ). 그러나 바람직하게는 일반 유형(예: Person8742468051c85b06f0a0af9e3e506b5c)을 사용하여 메서드나 클래스를 설계할 수 있습니다. 마찬가지로 Streams API와 같은 것을 사용할 때 람다 식을 전달하지만 더 나은 방법은 람다 매개 변수가 필요한 메서드를 만드는 것입니다.

하지만 이런 상황에 처했다면 여기 몇 가지 유용한 팁이 있습니다.

IntelliJ IDEA는 기능적 매개변수를 도입하는 데 도움이 될 수 있습니다.

이를 통해 누군가 객체 대신 람다를 전달하는 매개변수를 생성할 수 있습니다. 이 기능의 장점은 기존 기능 인터페이스가 사양과 일치함을 보여주는 것입니다.



결과는...

기존 기능적 인터페이스 사용

개발자가 Java 8 코드에 익숙해짐에 따라 다음을 볼 수 있습니다. 공급자 및 소비자와 같은 인터페이스를 사용할 때 어떤 일이 발생하는지, 그리고 로컬 ErrorMessageCreator(예를 들어)를 만드는 것이 어떻게 혼란스럽고 낭비가 될 수 있는지. 이 패키지를 살펴보고 이미 사용 가능한 항목을 확인하세요.

[email protected]/*  */

정말로 자신만의 기능적 인터페이스를 만들어야 한다면 이 주석으로 이렇게 표시하세요. 별 효과가 없어 보일 수도 있지만 IntelliJ IDEA는 인터페이스가 기능적 인터페이스에 사용되는 예외와 일치할 수 없는 경우 이를 알려줍니다. 재정의할 방법을 지정하지 않으면 다음이 표시됩니다.



너무 많은 방법을 지정하면 다음이 표시됩니다.



그리고 인터페이스 대신 클래스에 적용하면 다음과 같은 경고가 표시됩니다.



람다 표현식은 모든 단일 추상 메서드와 함께 사용할 수 있습니다. 인터페이스이지만 동일한 기준을 따르는 추상 클래스에서는 사용할 수 없습니다. 비논리적인 것 같지만 그게 전부입니다.

　4.Stream

　Stream API는 Java 8의 또 다른 큰 기능이며, 이것이 우리가 코딩하는 방식에 얼마나 많은 변화를 가져올지 실제로는 알 수 없다고 생각합니다. 제가 찾은 몇 가지 유용한 정보는 다음과 같습니다.

도트 연산자 대기열

저는 개인적으로 스트림 작업을 대기열에 넣는 것을 선호합니다. 물론, 이렇게 하는 것이 도움이 되었기 때문에 꼭 이렇게 할 필요는 없습니다.

어떤 작업을 수행했는지 한 눈에 확인하세요

디버깅이 더 쉽습니다(IntelliJ IDEA에서는 한 줄로 이 작업을 수행할 수 있는 기능 원하는 개수의 람다 표현식에 중단점을 설정할 수 있지만 여러 줄로 분할하면 더 쉬워집니다.)

테스트할 때 작업을 주석 처리하세요

디버깅이나 테스트를 위해 peek( )를 쉽게 삽입하세요



그리고 제 생각에는 더 깔끔합니다. 이 패턴을 따르면 코드 줄을 줄이는 측면에서 많은 이점을 얻을 수 없습니다.

도트 연산자를 정렬하려면 서식 설정을 조정해야 할 수도 있습니다.



메서드 참조 사용

예, 이 이상한 구문에 익숙해지려면 시간이 좀 걸립니다. 그러나 올바르게 사용하면 가독성이 높아집니다. 참조:



(상대적으로) 새로운 Objects 클래스의 도우미 메서드와 비교:



후자 코드 어떤 값을 저장할지 더 명확해졌습니다. IntelliJ IDEA는 일반적으로 람다가 메서드 참조로 축소될 수 있는 시기를 알려줍니다.



컬렉션을 반복할 때 Streams API

를 사용하거나 가능한 경우 forEach와 같은 새로운 컬렉션 방법을 사용하세요. IntelliJ IDEA가 제안하는 사항은 다음과 같습니다.



일반적으로 Streams API를 사용하는 것이 루프와 if 문을 조합하는 것보다 더 명확합니다. 예를 들면 다음과 같습니다.



IntelliJ IDEA에서는 다음과 같이 리팩토링할 수 있다고 제안합니다.



제가 수행한 성능 테스트에서 이 리팩토링이 나타났습니다. 놀라운 사실입니다. 성능이 동일하게 유지될지, 향상될지, 악화될지 항상 예측할 수 있는 것은 아닙니다. 항상 그렇듯이 성능이 응용 프로그램의 핵심이라면 한 스타일을 다른 스타일에 적용하기 전에 성능을 측정하십시오.

배열을 반복할 때 루프를 사용하세요

그러나 Java 8을 사용한다고 해서 어디에서나 스트림과 새로운 수집 방법을 사용해야 하는 것은 아닙니다. IntelliJ IDEA는 스트림으로의 변환을 제안하지만 이것이 "예"라고 대답해야 한다는 의미는 아닙니다. 확인이 억제되거나 꺼질 수 있다는 점을 기억하세요.

특히 기본 유형의 작은 배열에 대한 반복은 더 나은 성능과 아마도 (적어도 스트림을 처음 접하는 Java 개발자의 경우) 더 읽기 쉽게 사용되는 것이 거의 확실합니다.



다른 기술과 마찬가지로 규칙은 고정되어 있지 않지만 Streams API를 최대한 사용할지, 아니면 일부 작업에 루프를 계속 사용할지 결정해야 합니다. . 즉, 일관성을 유지하십시오.

드디어

날마다 새로운 것을 발견하고 있고 때로는 선호도가 바뀌기도 합니다. 내 코드에서 사용합니다. 이제 여러분의 조언을 듣고 싶습니다!

　

위 내용은 Java 8의 5가지 개발기술에 대한 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 주목해주세요!