[TIL] 자바의 Interface, Stream, Optional 등등

*20221201의 회고(벌써 12월이라니...)

 

 

   오늘은 아침 실시간 특강 시간에 자바의 interface, stream, optional 등에 대해 배웠다. 따라서 오늘 배운 내용에 대해 회고해보려 한다.

 

• 인터페이스(Interface)
  • 프론트와 백엔드의 접점. 프론트와 백의 통신 규약 → 프론트와 백이 동시 개발 가능
  • 다른 클래스를 작성할 때 기본이 되는 틀을 제공하면서, 다른 클래스 사이의 중간 매개 역할까지 담당하는 일종의 추상 클래스
  • 자바는 다중 상속을 허용하지 않음 -> 인터페이스로 다중상속을 흉내낼 수 있음
  • 인터페이스는 여러개 구현이 가능함
  • 추상메서드와 상수만을 포함하였으나, 자바8 부터 디폴트 메서드, 스테틱 메서드를 선언할 수 있음
  • 디폴트 메서드(default method)? - 인터페이스 내부에도 로직이 구현된 메서드를 선언할 수 있는데, default라는 접근 제어자를 꼭 명시해줘야 한다. -> 이를 통해 인터페이스를 구현한 클래스들을 수정하지 않아도 인터페이스에 기능을 추가해줄 수 있음 => 하위호환성은 유지하면서 인터페이스를 보완할 수 있음

 

• Promotion
  • 자동으로 일어나는 형 변환
  • 크기가 작은 자료형에서 크기가 큰 자료형으로 upcasting
  • 하위 클래스가 상위 인터페이스, 클레스, 추상클래스로 upcasting 되는 것
  • 모든 클래스는 Object로 upcasting 가능

 

• Dynamic Dispatch
  • 메서드 디스패치 : 어떤 메서드를 호출할지 결정하여 실제로 실행시키는 과정
  • 자바는 컴파일 시에는 생성할 객체 타입에 대한 정보만 보유함
  • 런타임 시 객체를 생성
  • Static Dispatch : 컴파일 시점에서, 컴파일러가 특정 메소드를 호출할 것이라고 명확하게 알고 있는 경우(오버로딩된 메서드)
  • Dynamic Dispatch : 컴파일러가 어떤 메서드를 호출하는지 모르는 경우. 동적 디스패치는 런타임 시점에 할당된 객체의 타입을 보고 메서드를 실행(오버라이딩 된 메서드)
  • 컴파일 타임이 아닌, 런타임에 upcasting 된 자식클래스의 오버라이딩 된 메소드를 호출한다.
  • 실행시간에 어떤 자식클래스의 오버라이딩 된 메소드를 호출할 지 명확해지기 때문
  • => promotion과 overriding을 통해 runtime polymorphism 즉 다형성을 구현할 수 있다.

 

• 함수형 인터페이스
  • 추상메서드를 하나만 가지고 있는 인터페이스
  • 자바는 클래스를 생성하지 않고는 메서드를 정의할 수 없음
  • 따라서 인터페이스를 선언하고 메서드를 선언 -> 함수처럼 사용

 

• 람다표현식
  • 메소드를 하나의 식으로 표현한 것
  • 익명 함수(Anonymous Function)를 지칭하는 용어(람다는 이름을 가질 필요가 없다) -> 모두 공통으로 일급 객체다
  • 일급 객체 : 다른 객체들에 적용 가능한 연산을 모두 지원하는 개체. 함수를 값으로 사용할 수 있고 파라미터로 사용할 수도 있음 
  • 메서드를 보다 간단하게 표현하는 방법
  • 장점 : 코드의 간결성, 지연 연산 수행, 병렬 처리 가능
  • 단점 : 호출이 까다로움, 가독성을 떨어 뜨릴 수 있음

 

• 메서드 레퍼런스 : 람다 표현식을 더 간단하게 표현하는 방법

@FunctionalInterface
public interface Sum {
	int intSum(int x, int y);
}
...
import ...Sum;

public class Main {
	Sum sum = (a, b) -> a + b;
    
    System.out.println(sum.intSum(1,2));
} //람다식

//위의 코드를 메소드 레퍼런스
...
import ...Sum;

public class Main {
	Sum sum = Integer::sum;
    
    System.out.println(sum.intSum(1,2));
}

 

• 스트림(Stream)
  • 데이터의 흐름
  • 배열이나 컬렉션에 담긴 데이터를 다룰 때, 반복문이나 iterator를 사용하면 코드가 길어지고 가독성이 떨어짐
  • 이를 해결하기 위해 Stream API가 등장함
  • 배열 또는 컬렉션 인스턴스에 함수 여러개를 조합해서 원하는 결과를 필터링 하고 가공된 결과를 얻음
  • 람다를 이용해서 코드의 양을 줄이고 간결하게 표현할 수 있음
  • 배열과 컬렉션을 함수형으로 처리할 수 있음
  • 스트림은 데이터를 변경하지 않는다 -> immutable(: 불변)
  • 스트림은 재사용이 불가 -> 최종 연산이 실행된 후 재사용 불가

 

• Optional<T> 클래스
  • NPE(Null Pointer Exception) 예외를 Optional이 제공하는 메소드로 간단하게 회피할 수 있다.
  • null이 올 수 있는 값을 감싸는 Wrapper 클래스
  • 예상치 못한 NPE 예외를 Optional 클래스에서 제공되는 메소드로 간단히 회피할 수 있음
  • 복잡한 조건문이 없이도 NPE를 처리할 수 있음
  • 잘못 사용하면 오히려 코드가 지저분해지고 의미없는 동작, side-effect 유발이 많이 발생할 수 있음
    • NPE는 물론이고 NoSuchElementException이 발생함
    • 잘못된 Optional 사용으로 새로운 문제들이 발생함
    • 코드의 가독성을 파괴
    • 시간, 공간적 비용이 증가함(결국 클래스를 하나 더 생성하고 이용하는 것이기 때문에)
  • null을 반환하면 오류가 발생할 가능성이 매우 높은 경우에 "결과 없음"을 명확하게 드러내기 위해 메소드의 반환 타입으로 사용되도록 매우 제한적인 경우로 설계됨
  • Optional은 메소드 반환 타입으로만 사용해야 한다.

 

 

   오늘은 이정도로 정리하겠다. 자바의 문법만 알면 자바공부는 끝날 줄 알았는데, 이렇게 깊은 내용들이 있다는 사실이 신기했다. 내일까지 자바 심화 특강이 있다. 내일은 또 어떤 내용을 배우게 될지 기대가 된다. 그리고 튜터님이 추천해주신 이펙티브 자바 3rd 에디션, 스프링 입문, 클린 코드 책을 모두 구입했다. 확실히 프로그래밍은 변화가 빠르다 보니 책으로 공부하는 것 보다 시시 각각 새로 나오는 공식 문서 등을 참고하여 공부하는게 좋다고 하였지만, 정말 변하지 않는 기본적인 내용이나 기본 소양 같은 부분은 책으로 공부하는게 맞다고 생각한다. 또한 그게 머릿속에 더 잘 들어오는 것 같다. 책들이 배송이 되면 어서 들여다 보고 싶다.

   다음주 부터는 스프링을 배우게 된다. 내배캠을 시작할 때에는 자바문법을 다 하고 들어왔기 때문에, 조금은 편한 마음으로 공부를 한 것도 없지 않아 있었다. 그러나 스프링은 정말 처음부터 배우는 것이나 다름이 없기 때문에 이제 확실히 긴장하고 정신차려야 할 것 같다. 지식을 채워넣는 것과 하루하루 성장해 나감에 집중하고 또 감사하자. 오늘의 회고 끝!