람다, 스트림 프로그래

업데이트:

컬렉션 팩토리(자바 9)

리스트 팩토리

  • List.of 팩토리 메소드를 이용해서 간단하게 리스트를 만들 수 있다.
  • 고정된 배열로 데이터를 추가하면 에러가 발생한다.
    List<String> friends = List.of("aa", "bb", "cc");
    friends.add("dd")  // UnsupportedOperationException
    

집합 팩토리

  • List.of와 비슷한 방법으로 바꿀 수 없는 집함을 만들 수 있다.
    Set<String> friends = Set.fo("aa", "bb","cc");
    

맵 팩토리

  • Map.of 팩토리 메서드에 키와 값을 번갈아 제공하는 방법으로 맵을 만들 수 있다.
  • 열개 이하의 키와 값 쌍을 가진 작은 맵을 만들 때는 이 메소드가 유용하다.
    Map<String, Integer> ageOfFriends = Map.of("aa",1, "bb",2,"cc",3);
    
  • 열개 이상은 Map.Entry<K,V> 객체를 인수로 받으며 가변 인수로 구현된 Map.ofEntries 팰토리 메서드를 이용하는 것이 좋다.
    Map<String, Integer> ageOfFriends = Map.ofEntries(entry("aa",1),
                                                    entry("bb",2),
                                                    entry("cc",3));
    
리팩토링

익명클래스를 람다 표현식으로 리팩터링 하기

  • 하나의 추상 메서드를 구현하는 익명 클래스는 람다 표현식으로 리팩터링할 수 있다. 익명 클래스는 코드가 장황하게 만들어지고 쉽게 에러를 일으킬 가능성이있어 람다 표현식을 사용하여 간결하고, 가독성이 좋은 코드를 구현할 수 있다.
  • 모든 익명 클래스를 람다 표현식으로 변환할 수 있는 것은 아니다. 익명 클래스에서 사용한 this는 익명클래스 자심을 가리키지만 람다에서 this는 람다를 감싸는 클래스를 가리킨다.
  • 익명 클래스는 감싸고 있는 클래스 변수를 가릴 수 있다.(새도 변수) 하지만 람다 표현식으로는 변수를 가릴 수 없다.
  • 익명 클래스를 람다 표현식으로 바꾸면 콘텍스트 오버로딩에 따른 모호함이 초래될 수 있다. 익명 클래스는 인스턴스화 할때 명시적으로 형식이 정해지는 반면에 람다 형식은 콘텍스트에 다라 달라지기 때문이다. ``` java // 익명 클래스를 사용한 코드 Runnable r1 = new Runnable() { public void run(){ System.out.println(“Hello”); } }; // 람다 표현식을 사용한 코드 Runable r2 = () -> System.out.println(“Hello”)

// 익명 클래스를 사용한 코드 Runnable r1 = new Runnable() { public void run(){ int a = 10; System.out.println(a); } };

// 람다 표현식을 사용한 코드 에러 발생 Runable r2 = () -> int a = 2; System.out.println(“Hello”) ```

람다 표현식을 메서드 참조로 리팩터링 하기

  • 람다 표현식은 쉽게 전달할수 있는 코드다. 하지만 람다 대신 메서드 참조를 이용하면 가독성을 높일 수 잇다.

명령형 데이터 처리를 스트림으로 리팩터링 하기

  • 이론적으로 반복자를 이용한 기존의 모든 컬레션 처리 코드를 스트림 API로 바꿔야 한다. 스트림 API는 데이터 처리 파이프라인의 의도를 더 명확하게 보여준다.
도메인 전용 언어

DSL은 특정 비즈니스 도메인의 문제를 해결하려고 만든 언어다. 예를 들어 회계 전용 소프트웨어 애플리케이션을 개발한다고 가정하자. 이 상황에서 비즈니스 도메인에는 통장 입출금 내역서, 계좌통합 같은 개념이 포함된다. 이런 문제를 표현할 수 있는 DSL만들 수 있다.

  • 의사 소통의 왕 : 우리의 코드의 의도가 명확히 전달되어야 하며 프로그래머가 아닌 사람도 이해할 수 있어야 한다.
  • 한번 코드를 구현하지만 여러 번 읽는다 : 가독성은 유지보수의 핵심이다. 즉 항상 우리의 동료가 쉽게 이해할 수 있도록 코드를 구현해야 한다.
  • 장점 :간결함, 가독성, 유지보수, 높은 수준의 추상화, 집중, 관심사 분리
  • 단점 : DSL 설계의 어려움, 개발 비용, 추가 우회 계층, 새로 배워야 하는 언어, 호스팅 언어 한계

댓글남기기