Java 8 개발을 위한 주요 팁

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

1. 선택사항

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

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

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

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

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

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

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

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

isPresent()와 get()을 결합하면 정말 좋을 것 같아요...

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

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

2. 람다 표현식 사용

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

짧게 유지하세요

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

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

명시적

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

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

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

3. 람다 표현식을 위한 설계

내 생각에 람다 표현식은 제네릭과 다소 유사하다고 생각합니다. 제네릭과 함께 자주 사용하지만(예: List에 유형 정보 추가), 더 나은 방법은 제네릭을 사용하여 메서드를 설계하는 것입니다. 유형의 클래스( 예: Person<t></t>). 마찬가지로 Streams API와 같은 것을 사용할 때 람다 식을 전달하지만 더 나은 방법은 람다 매개 변수가 필요한 메서드를 만드는 것입니다.

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

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

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

이로 인해...

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

개발자가 점점 익숙해질수록 우리는 Java 8 코드를 사용하고 있으며 Supplier 및 Consumer와 같은 인터페이스를 사용할 때 어떤 일이 발생하는지, 그리고 로컬 ErrorMessageCreator(예를 들어)를 생성하는 것이 어떻게 혼란스럽고 낭비가 될 수 있는지 알고 있습니다. 이 패키지를 살펴보고 이미 사용 가능한 항목을 확인하세요.

기능적 인터페이스에 @FunctionalInterface 추가

정말로 자신만의 기능적 인터페이스를 만들어야 한다면 이 주석으로 표시하세요. 별 효과가 없어 보일 수도 있지만 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 개발 스킬 상위 내용입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 주목해주세요!