[자바] 자바 8에 새롭게 변화된 기능들

자바 8로 오면서 많은 부분이 바뀌게 되었다. 오늘 날 배포 환경에서는 8이나 11 버전을 많이 사용하는 것으로 알려져 있는데 무엇이 추가되었는지 알아보자

목차

1. 람다 표현식

2. 스트림 API

3. Optional

4. Interface의 Default 메소드

5. 날짜 관련 클래스

 

람다 표현식

• 자바8부터 지원
• 함수형 프로그래밍 지원
• 메소드를 하나의 식으로 표현한 것
• 메소드를 람다식으로 표현하면 메소드의 이름과 반환타입이 없으므로, 익명함수라고도 한다.

람다식 장단점

• 장점
  • 코드가 간결, 가독성이 좋다.
  • 함수 만드는 과정 없이 한번에 처리 가능
  • 병렬 프로그래밍 용이
• 단점
  • 디버깅이 까다롭다.
  • 재귀식에는 부적합

 

스트림 API

• (이것이 자바다) Collections 또는 Array의 요소를 하나 씩 참조해 람다식으로 처리할 수 있는 반복자
• (우아한 Tech) 데이터 Collections의 반복을 멋.지.게 처리하는 기능이다!
• (남궁성의 정석코딩) 다양한 데이터 소스를 표준화된 방법으로 다루기 위한 것!

스트림의 특징

• 원본을 건드리지 않는다. ReadOnly
• Iterator처럼 1회용이다.

 

Optioanal

예외 중 가장 많이 마주칠 수 있는 예외는 Null Pointer Exception이다. 자바는 null 검사를 해야 하는 문제때문에 코드가 복잡해지고 번거로운데 이러한 문제 개선을 위해 optional 객체가 나오게 되었다.

+ 클린 코드

+ Null-Safe

public final class Optional<T> {

  // If non-null, the value; if null, indicates no value is present
  private final T value;
  ...
}

 

[꼬리질문] Optional에는 orElse와 orElseGet 메소드가 있는데 둘은 어떤 차이가 있나요?
orElse은 파라미터로 객체를 받는다.
orElseGet은 파라미터로 Supplier 라는 함수를 파라미터로 받는다.
orElse는 객체가 null이든 아니든 무조건 실행하기 때문에 null이 발생할 수 있는 상황이라면 orElseGet 사용을 해야 한다.
orElse는 값을 무조건 생성하기 때문에 리소스가 추가되는 소모가 있다. 이러한 특징을 알고 잘 사용해야 한다.

Optional을 잘 사용 못 한다면,,

• NPE 대신 NoSuchElementException 발생 가능성
• 코드 가독성 저해
• 오버헤드 증가

 

Optinal 사용법 가이드

• Optional 변수에 Null을 할당하지 말아라 -> 값이 없는 경우는 Optional.empty()로 초기화
• isPresent는 안티 패턴으로 사용하지 마라 -> isPresent는 추가적인 if문이 필요해 가독성을 저해한다.
  • ifPresentOrElse
  • orElseThrow -> 가장 많이 사용하게 된다.
• 생성자, 수정자, 메소드 파라미터 등으로 넘기지 마라
  • 파라미터로 Optional을 넘기는 행위는 추가적인 null가 필요하다.
• Collection의 경우 Optional이 아닌 빈 Collection을 사용하라
  • Collection 객체들은 Optional로 감싸지 않고, 빈 컬렉션(new ArrayList<>())로 감싸는 것이 훨씬 낫다.
• 반환 타입으로만 사용하라 -> 반환 타입으로 사용해 에러 발생할 수 있는 곳에서 미리 예외를 발생해 반환 객체가 문제가 없음을 드러내기 위해 사용하고, Stream과 결합해 유연한 체이닝 API를 위해 탄생햇다. + 실제로 Optional을 아무 곳이나 사용하는 분을 보았고 여러 리소스가 소모되며 가독성이며, 코드 복잡성 또한 야기하는걸 목격했다.

 

Interface에 Default Method 추가

인터페이스는 본래 기능 선언만을 목적으로 만든다. 그러나 자바 8에서부터 기본 메서드로 default가 추가되어 내부에도 로직이 추가될 수 있게 되었다.

 

왜 추가됐나요?

문제점 : 인터페이스에 메서드를 추가하게 되면 모든 구현체에 구현을 해야만 하는 문제로 OCP 원칙 위반

해결법 : 인터페이스에 default method를 사용하면 추가 구현에도 열려있어 OCP 원칙을 지킬 수 있다.

 

 

날짜 관련 클래스 추가

기존 날짜 클래스의 문제점

• 불변 객체가 아니다 - 이로 인해 별칭 문제, 분산 환경에서 불안정성을 야기하게 된다
• 상수 필드의 남용 - 다른 값이 들어가도 컴파일 단계에서 확인할 수 없다.
• 일관성 없는 요일 상수 - 요일 상수가 메소드마다 달라 사용하기 애매하다.

 

JSR-310: 새로운 Java의 날짜 API 두둥등장

• 요일이 ENUM 상수로 제공되어 잘못 지정할 여지가 없다.
• 생성자 대신 정적 팩토리 메서드 패턴을 사용해 재활용하기 좋다.
• 밀리초까지만 다룰 수 있었으나 나노초까지 다룰 수 있게 되었다.

 

 

자바 7에서 추가된 Try-with-resource란?

• try에 리소스를 선언하고, 다 사용하면 반납(close) 해주는 기능
• Java 7 이후에 추가된 기능이다.
• Java 7 이전에는 Try-catch-finally를 사용한다.
• AutoCloseable가 구현된 클래스만 반납이 구현이 가능하다.

 

결론 ~ 

나는 사실 자바8 이전의 버전을 사용해본적이 없어 해당 사항들에 대한 불편함을 느끼지 못했었다. 그러나 만약 위의 기능들이 없다면 너무나 절망적이었을 것 같다. 스트림을 너무나도 잘 사용하고 있고 코드를 깔끔하게 해주는데 도움을 주는 API이기 때문이다.

Data, Time 클래스만 있었다면 끔찍했을거 같다. 안그래도 날짜 개념이 헷갈리는데 상상하기도 싫다,,

 

참고 자료

https://mangkyu.tistory.com/3

https://d2.naver.com/helloworld/645609