🐾
개발자국
  • 🐶ABOUT
  • 🚲프로그래밍
    • 객체 지향 프로그래밍
    • 오브젝트
      • 1장: 객체, 설계
      • 2장: 객체지향 프로그래밍
      • 3장: 역할, 책임, 협력
      • 4장: 설계 품질과 트레이드오프
      • 5장: 책임 할당하기
      • 6장: 메시지와 인터페이스
      • 7장: 객체 분해
      • 8장: 의존성 관리하기
      • 9장: 유연한 설계
      • 10장: 상속과 코드 재사용
      • 11장: 합성과 유연한 설계
      • 12장: 다형성
      • 13장: 서브클래싱과 서브타이핑
      • 14장: 일관성 있는 협력
      • 15장: 디자인 패턴과 프레임워크
    • 도메인 주도 개발 시작하기
      • 1장: 도메인 모델 시작하기
      • 2장: 아키텍처 개요
      • 3장: 애그리거트
      • 4장: 리포지토리와 모델 구현
      • 5장: 스프링 데이터 JPA를 이용한 조회 기능
      • 6장: 응용 서비스와 표현 영역
      • 7장: 도메인 서비스
      • 8장: 애그리거트 트랜잭션 관리
      • 9장: 도메인 모델과 바운디드 컨텍스트
      • 10장: 이벤트
      • 11장: CQRS
    • 클린 아키텍처
      • 만들면서 배우는 클린 아키텍처
        • 계층형 아키텍처의 문제와 의존성 역전
        • 유스케이스
        • 웹 어댑터
        • 영속성 어댑터
        • 아키텍처 요소 테스트
        • 경계 간 매핑 전략
        • 애플리케이션 조립
        • 아키텍처 경계 강제하기
        • 지름길 사용하기
        • 아키텍처 스타일 결정하기
    • 디자인 패턴
      • 생성(Creational) 패턴
        • 팩토리 패턴
        • 싱글톤 패턴
        • 빌더 패턴
        • 프로토타입 패턴
      • 행동(Behavioral) 패턴
        • 전략 패턴
        • 옵저버 패턴
        • 커맨드 패턴
        • 템플릿 메서드 패턴
        • 반복자 패턴
        • 상태 패턴
        • 책임 연쇄 패턴
        • 인터프리터 패턴
        • 중재자 패턴
        • 메멘토 패턴
        • 비지터 패턴
      • 구조(Structural) 패턴
        • 데코레이터 패턴
        • 어댑터 패턴
        • 퍼사드 패턴
        • 컴포지트 패턴
        • 프록시 패턴
        • 브리지 패턴
        • 플라이웨이트 패턴
      • 복합 패턴
  • 시스템 설계
    • 1. 사용자 수에 따른 규모 확장성
    • 2. 개략적 규모 추정
    • 3. 시스템 설계 접근법
    • 4. 처리율 제한 장치
    • 5. 안정 해시
    • 6. 키-값 저장소
    • 7. 유일한 ID 생성기
    • 8. URL 단축기
    • 9. 웹 크롤러
    • 10. 알림 시스템
    • 11. 뉴스 피드
    • 12. 채팅 시스템
    • 13. 검색어 자동완성
    • 14. 유튜브 스트리밍
    • 15. 구글 드라이브
    • ⭐️. 캐싱 전략
    • ⭐️. 재고 시스템으로 알아보는 동시성이슈 해결방법
    • ⭐️. 실습으로 배우는 선착순 이벤트 시스템
  • 🏝️자바
    • 자바의 내부 속으로
      • Java 언어의 특징
      • JDK
      • JVM
        • 메모리 관리
        • Garbage Collector
          • 기본 동작
          • Heap 영역을 제외한 GC 처리 영역
          • (WIP) GC 알고리즘
        • 클래스 로더
      • 자바 실행 방식
      • 메모리 모델과 관리
      • 바이트 코드 조작
      • 리플렉션
      • 다이나믹 프록시
      • 어노테이션 프로세서
    • 자바의 기본
      • 데이터 타입, 변수, 배열
    • 이펙티브 자바
      • 2장: 객체의 생성과 파괴
        • item 1) 생성자 대신 정적 팩토리 메서드를 고려하라
        • item2) 생성자에 매개변수가 많다면 빌더를 고려하라
        • item3) private 생성자나 열거 타입으로 싱글톤임을 보증하라
        • item4) 인스턴스화를 막으려면 private 생성자를 사용
        • item5) 자원을 직접 명시하는 대신 의존 객체 주입 사용
        • item6) 불필요한 객체 생성 지양
        • item7) 다 쓴 객체는 참조 해제하라
        • item8) finalizer와 cleaner 사용 자제
        • item9) try-with-resources를 사용하자
      • 3장: 모든 객체의 공통 메서드
        • item 10) equals는 일반 규약을 지켜 재정의 하자
        • item 11) equals 재정의 시 hashCode도 재정의하라
        • item 12) 항상 toString을 재정의할 것
        • item 13) clone 재정의는 주의해서 진행하라
        • item 14) Comparable 구현을 고려하라
      • 4장: 클래스와 인터페이스
        • item 15) 클래스와 멤버의 접근 권한을 최소화하라
        • item 16) public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
        • item 17) 변경 가능성을 최소화하라
        • item 18) 상속보다는 컴포지션을 사용하라
        • item 19) 상속을 고려해 설계하고 문서화하고, 그러지 않았다면 상속을 금지하라
        • item 20) 추상 클래스보다는 인터페이스를 우선하라
        • item 21) 인터페이스는 구현하는 쪽을 생각해 설계하라
        • item 22) 인터페이스는 타입을 정의하는 용도로만 사용하라
        • item 23) 태그 달린 클래스보다는 클래스 계층구조를 활용하라
        • item 24) 멤버 클래스는 되도록 static으로 만들라
        • item 25) 톱레벨 클래스는 한 파일에 하나만 담으라
      • 5장: 제네릭
        • item 26) 로 타입은 사용하지 말 것
        • item 27) unchecked 경고를 제거하라
        • item 28) 배열보다 리스트를 사용하라
        • item 29) 이왕이면 제네릭 타입으로 만들라
        • item 30) 이왕이면 제네릭 메서드로 만들라
        • item 31) 한정적 와일드카드를 사용해 API 유연성을 높이라
        • item 32) 제네릭과 가변 인수를 함께 사용
        • item 33) 타입 안전 이종 컨테이너를 고려하라
      • 6장: 열거 타입과 어노테이션
        • item 34) int 상수 대신 열거 타입을 사용하라
        • item 35) ordinal 메서드 대신 인스턴스 필드를 사용하라
        • item 36) 비트 필드 대신 EnumSet을 사용하라
        • item 37) ordinal 인덱싱 대신 EnumMap을 사용하라
        • item 38) 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라
        • item 39) 명명 패턴보다 어노테이션을 사용하라
        • item 40) @Override 어노테이션을 일관되게 사용하라
        • item 41) 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라
      • 7장: 람다와 스트림
        • item 42) 익명 클래스보다는 람다를 사용하라
        • item 43) 람다보다는 메서드 참조를 사용하라
        • item 44) 표준 함수형 인터페이스를 사용하라
        • item 45) 스트림은 주의해서 사용하라
        • item 46) 스트림에서는 부작용 없는 함수를 사용하라
        • item 47) 반환 타입으로는 스트림보다 컬렉션이 낫다
        • item 48) 스트림 병렬화는 주의해서 적용하라
      • 8장: 메서드
        • item 49) 매개변수가 유효한지 검사하라
        • item 50) 적시에 방어적 복사본을 만들라
        • item 51) 메서드 시그니처를 신중히 설계하라
        • item 52) 다중정의는 신중히 사용하라
        • item 53) 가변인수는 신중히 사용하라
        • item 54) null이 아닌, 빈 컬렉션이나 배열을 반환하라
        • item 55) 옵셔널 반환은 신중히 하라
        • item 56) 공개된 API 요소에는 항상 문서화 주석을 작성하라
      • 9장: 일반적인 프로그래밍 원칙
        • item 57) 지역 변수의 범위를 최소화하라
        • item 58) 전통적인 for문보다 for-each문을 사용하기
        • item 59) 라이브러리를 익히고 사용하라
        • item 60) 정확한 답이 필요하다면 float, double은 피하라
        • item 61) 박싱된 기본타입보단 기본 타입을 사용하라
        • item 62) 다른 타입이 적절하다면 문자열 사용을 피하라
        • item 63) 문자열 연결은 느리니 주의하라
        • item 64) 객체는 인터페이스를 사용해 참조하라
        • item 65) 리플렉션보단 인터페이스를 사용
        • item 66) 네이티브 메서드는 신중히 사용하라
        • item 67) 최적화는 신중히 하라
        • item 68) 일반적으로 통용되는 명명 규칙을 따르라
      • 10장: 예외
        • item 69) 예외는 진짜 예외 상황에만 사용하라
        • item 70) 복구할 수 있는 상황에서는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
        • item 71) 필요 없는 검사 예외 사용은 피하라
        • item 72) 표준 예외를 사용하라
        • item 73) 추상화 수준에 맞는 예외를 던지라
        • item 74) 메서드가 던지는 모든 예외를 문서화하라
        • item 75) 예외의 상세 메시지에 실패 관련 정보를 담으라
        • item 76) 가능한 한 실패 원자적으로 만들라
        • item 77) 예외를 무시하지 말라
      • 11장: 동시성
        • item 78) 공유 중인 가변 데이터는 동기화해 사용하라
        • item 79) 과도한 동기화는 피하라
        • item 80) 스레드보다는 실행자, 태스크, 스트림을 애용하라
        • item 81) wait와 notify보다는 동시성 유틸리티를 애용하라
        • item 82) 스레드 안전성 수준을 문서화하라
        • item 83) 지연 초기화는 신중히 사용하라
        • item 84) 프로그램의 동작을 스레드 스케줄러에 기대지 말라
      • 12장: 직렬화
        • item 85) 자바 직렬화의 대안을 찾으라
        • item 86) Serializable을 구현할지는 신중히 결정하라
        • item 87) 커스텀 직렬화 형태를 고려해보라
        • item 88) readObject 메서드는 방어적으로 작성하라
        • item 89) 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라
        • item 90) 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라
    • 모던 자바 인 액션
      • 1장: 자바의 역사
      • 2장: 동작 파라미터화
      • 3장: 람다
      • 4장: 스트림
      • 5장: 스트림 활용
      • 6장: 스트림으로 데이터 수집
      • 7장: 병렬 데이터 처리와 성능
      • 8장: 컬렉션 API 개선
      • 9장: 람다를 이용한 리팩토링, 테스팅, 디버깅
      • 10장: 람다를 이용한 DSL
      • 11장: null 대신 Optional
      • 12장: 날짜와 시간 API
      • 13장: 디폴트 메서드
      • 14장: 자바 모듈 시스템
      • 15장: CompletableFuture와 Reactive 개요
      • 16장: CompletableFuture
      • 17장: 리액티브 프로그래밍
      • 18장: 함수형 프로그래밍
      • 19장: 함수형 프로그래밍 기법
      • 20장: 스칼라 언어 살펴보기
    • 자바의 이모저모
      • Javax
      • Objects
      • NIO
      • Thread
      • Concurrent
        • Atomic
        • Executor, ExecutorService
        • Interrupt
      • Assertions
    • Netty
      • 네티 맛보기
      • 네티의 주요 특징
      • 채널 파이프라인
      • 이벤트 루프
      • 바이트 버퍼
      • 부트스트랩
      • 네티 테스트
      • 코덱
      • 다양한 ChannelHandler와 코덱
      • 웹소켓
      • UDP 브로드캐스팅
    • 자바 병렬 프로그래밍
      • 2장: 스레드 안전성
      • 15장: 단일 연산 변수와 논블로킹 동기화
  • 🏖️코틀린
    • 코틀린 인 액션
      • 코틀린 언어의 특징
      • 코틀린 기초
      • 함수 정의와 호출
      • 클래스, 객체, 인터페이스
      • 람다
      • 타입 시스템
      • 연산자 오버로딩과 기타 관례
      • 고차 함수
      • 제네릭스
      • 어노테이션과 리플렉션
      • DSL 만들기
  • 🌸스프링
    • Spring Core
      • Cron Expression
      • Bean
        • Lifecycle
        • Aware
    • Spring MVC
    • Spring Security
      • 로그인 처리
      • 로그아웃 처리
      • JWT 인증 방식
      • 메소드별 인가 처리
    • Spring Data
      • Pageable
      • Spring Data Couchbase
      • Spring Data Redis
        • Serializer
    • Spring REST Docs
    • Spring Annotations
    • Spring Cloud
      • Service Discovery
      • API Gateway
      • Spring Cloud Config
      • MicroService Communication
      • Data Synchronization
    • Test
      • 테스트 용어 정리
      • JUnit
      • Spring Boot Test
      • Mockito
    • QueryDSL
      • 프로젝트 환경설정
      • 기본 문법
      • 중급 문법
      • 순수 JPA와 QueryDSL
      • 스프링 데이터 JPA와 QueryDSL
    • Lombok
      • @Data
      • @Builder
      • Log Annotations
  • 🕋DB
    • MySQL
      • CentOS7에서 MySQL 8 버전 설치하기
    • MongoDB
      • 
    • Redis
      • Sentinel
      • Cluster
      • Transaction
      • 자료구조
        • String
        • List
        • Set
        • Hash
        • Bitmaps
        • SortedSet
      • Lettuce 단일 서버, 클러스터 서버, 풀링 사용 방법
  • 📽️인프라
    • 리눅스
      • 주요 명령어 모음
    • Docker
      • Docker
      • Docker Compose
      • Docker Swarm
      • Docker Network
      • Linux에서 root 아닌 유저로 docker 실행하기
    • Kubernetes
      • 기초 개념
      • Pod
      • Configuration
      • ReplicationSet
      • Network
      • ConfigMap & Secret
      • Volume, Mount, Claim
      • Controller
      • Multi Container Pod
      • StatefulSet & Job
      • Rollout & Rollback
      • Helm
      • 개발 워크플로우와 CI/CD
      • Container Probes
      • Resource Limit
      • Logging & Monitoring
      • Ingress
      • Security
      • Multi Node/Architecture Cluster
      • Workload & Pod management
      • CRD & Operator
      • Serverless Function
      • K8S Cheat Sheet
    • Kafka
      • 카프카 개요
      • 카프카 설치 및 실습
      • Kafka Broker
      • Topic, Partition, Record
      • Producer
      • Consumer
      • Kafka Streams
      • Kafka Connect
      • MirrorMaker
  • AWS
    • AWS Console / CLI / SDK
    • IAM
    • EC2
      • EC2 Advanced
    • ELB / ASG
    • RDS / Aurora / ElastiCache
    • DynamoDB
    • DocumentDB / Neptune / Keyspaces / QLDB / Timestream
    • Route 53
    • Beanstalk
    • Solution Architect
    • S3
      • 보안
    • CloudFront
    • Global Accelerator
    • AWS Storage
    • Messaging
    • Container
    • Serverless
    • Data Analysis
    • Machine Learning
    • Monitoring
    • Security
    • VPC
    • Data Migration
    • 기타 서비스
  • 🏔️CS
    • 운영 체제
      • Introduction
      • System Structures
      • Process
      • Synchronization
      • Muitithreaded Programming
      • Process Scheduling
      • Memory Management
      • Virtual Memory
    • 네트워크
      • 네트워크 기초
      • 네트워크 통신 방식
      • OSI 7계층
        • 1계층: 물리계층
        • 2계층: 데이터 링크 계층
        • 3계층: 네트워크 계층
        • 4계층: 전송 계층
        • 5계층: 세션 계층
        • 6계층: 표현 계층
        • 7계층: 응용 계층
      • TCP/IP 스택
      • ARP
      • 데이터 크기 조절
      • WDM
      • NAT
      • DNS
      • DHCP
      • VPN
      • 네이글 알고리즘
      • 서버 네트워크
      • 네트워크 보안
        • 보안의 기본
        • 보안 장비
      • 이중화
    • 데이터베이스
      • 트랜잭션
    • 컴퓨터 구조
      • 개요
      • Instruction Set Architecture
      • Procedure Call & Return
      • Linking
      • Pipeline
      • Memory Hierarchy
      • Virtual Memory
      • Interrupt / Exception, IO
    • 자료 구조
      • Array
      • List
      • Map
      • Set
      • Queue
      • PriorityQueue
      • Stack
    • 웹 기술
      • HTTP
        • 쿠키와 세션
  • 🪂Big Data
    • Apache Hadoop
  • 🕹️ETC
    • Git
      • 내부 구조
      • 내가 자주 사용하는 명령어 모음
      • Commit Convention
    • 이력서 작성하기
    • Embedded
      • 라즈베리파이에서 네오픽셀 적용기
    • 기술블로그 모음집
Powered by GitBook
On this page

Last updated 1 year ago

리팩토링

  • 코드 가독성을 높이려면 코드의 문서화를 잘하고 표준 코딩 규칙을 준수하는 등의 노력이 필요하다.

  • 자바 8의 람다, 메서드 참조, 스트림을 활용하여 기존 코드의 가독성을 개선할 수 있다.

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

  • 익명 클래스는 코드를 장황하게 만들고 쉽게 에러를 일으키기 때문에 람다를 사용도록 변경해 간결하고 가독성 좋은 코드를 구현할 수 있다.

  • 익명 클래스와 람다에서의 this, super 지시자는 다른 의미를 갖는다.

    • 익명 클래스의 this는 자기 자신의 클래스를 의미하지만, 람다의 this는 람다를 감싸는 클래스를 의미한다.

  • 익명 클래스는 감싸고 있는 클래스의 변수를 가릴수 있지만, 람다 표현식으로는 가릴수 없다.

  • 익명 클래스는 인스턴스화 할때 명시적으로 형식이 정해지는 반면 람다의 형식은 콘텍스트에 따라 달라지기 때문에 익명 클래스를 람다 표현식으로 변경하면 콘텍스트 오버로딩에 따른 모호함이 발생한다.

  • 아래와 같이 람다식이 Task 구체 클래스와 Runnable 구체 클래스 중 어떤 것인지 알 수 없게된다. 따라서 명시적 형변환을 해주어야 해결할 수 있다.

  • 인텔리제이에서도 이 부분에 대해 오류가 있다고 감지해주며, 명시적 형변환을 하도록 제안해주고 있다.

람다 표현식을 메서드 참조로 리팩토링

  • comparing이나 maxBy , groupingBy 같은 정적 헬퍼 메서드를 메서드 참조와 조합해 사용할 수 있다.

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

  • 스트림 API는 데이터 처리 파이프라인의 의도를 명확하게 보여주고 최적화할 수 있으며 멀티코어 아키텍처를 쉽게 활용할 수 있도록 한다.

코드 유연성 개선

  • conditional deferred execution 패턴

    • 클라이언트 코드에서 객체 상태를 자주 확인하거나 객체의 일부 메서드를 호출하는 상황이라면 내부적으로 객체의 상태를 확인한 후 메서드를 호출하도록 하는 새로운 메서드를 구현하는 것이 좋다.

    • 아래는 3단계를 거쳐 리팩토링한 것으로, 조건에 맞는 상황이 되었을 때에만 메시지를 생성하도록 지연하는 conditional defferred execution 패턴을 사용했다.

  • execute around 패턴

    • 매번 같은 준비, 종료 과정을 반복하는 코드를 람다로 변환하여 재사용할 수 있다.

    • 아래는 file.txt 파일을 try-with-resource 문으로 접근하는 과정을 템플릿화 하고, 내부적으로 파일의 데이터를 어떻게 처리할지는 함수형 인터페이스인 BufferedReaderProcessor를 구현한 람다로 작성하도록 해 execute around 패턴을 구현한 예제이다.

람다와 디자인 패턴

전략 패턴

  • 전략 클래스에서는 다양하게 갈아끼울 수 있도록 인터페이스필드를 가지고 있으며, 이 인터페이스 필드에 구체적인 구현 클래스가 주입되는 패턴이다.

  • 전략 패턴에서 구현 클래스를 주입할 때 직접 구체 클래스를 정의하고 인스턴스를 생성하는 대신 람다를 사용해 간단히 주입할 수 있다.

  • 아래 예제에서는 String을 입력받아 유효성을 검사할 수 있는 ValidationStrategy 인터페이스를 Validator 전략 클래스가 필드로 가지고 있으며, 이 전략 클래스 내부에서 어떻게 유효성 검사를 할 지는 람다로 주입받도록 한다.

템플릿 메서드 패턴

  • 템플릿 메서드 패턴이란 변하는 부분을 추상 클래스의 추상 메서드를 구현하도록 하고 변하지 않는 부분은 추상 클래스의 메서드에 구현해두는 방식이다.

  • 람다를 사용할 경우 아래와 같이 추상 클래스의 추상 메서드를 두는 대신 람다식을 입력받아 수행하도록 할 수 있다.

옵저버 패턴

  • 어떤 이벤트가 발생했을 때 한 객체(Subject)가 다른 객체 리스트(Observer)에 자동으로 알림을 보내야 하는 패턴에서 옵저버 디자인 패턴을 사용한다.

  • NotiSubject 인터페이스에서 새로운 메시지를 notifyObservers 메서드를 통해 발행하면 등록된 모든 Observer로 해당 메시지가 전달되어 Observer의 notify 메서드가 호출된다.

  • 이 옵저버 패턴에서 각 Observer 구현체를 만들지 않고 람다식을 넘겨 옵저버를 등록하여 코드를 간결하게 만들 수 있다.

  • 람다 표현식으로 불필요한 코드가 제거 되는것이 바람직하다 할때만 람다식으로 사용하는 것을 권장한다.

  • 복잡한 로직이나 여러 메서드가 정의된다면 람다 표현식 보다 기존 방식을 고수하는 것이 오히려 가독성이 좋다.

의무 체인 패턴

  • 작업 처리 객체의 체인을 만들 때 사용하는 패턴으로 한 객체가 작업을 처리한 다음 다른 객체로 결과를 전달하고 다음 객체가 작업을 처리후 그 다음 객체로 전달하는 형식이다.

  • 일반적으로 아래와 같이 추상 클래스에 다음 객체를 필드로 갖고 있다가 본 클래스의 작업이 끝나면 다음 클래스의 작업을 수행해 결과를 반환한다.

  • 람다를 사용하여 UnaryOperator<String> 타입을 만들면, 구체 클래스를 생성하지 않고도 간단하게 부가 작업을 담당하는 구성 요소들을 만들어 체이닝할 수 있다.

정적 팩토리 메서드 보완

  • 인스턴스화 로직을 클라이언트에 노출하지 않고 객체를 만들 때 정적 팩토리 메서드를 사용한다.

  • 아래는 상품명을 입력받아 상품 객체를 생성해 반환하는 메서드이다.

  • 위와 같은 정적 팩토리 메서드를 람다를 사용해 아래와 같이 구현할 수 있다. (개인적으로는 이 부분은 람다 사용하지 않는 것이 더 깔끔해보인다.)

테스팅

보이는 람다 표현식의 동작 테스트

  • 람다식은 함수형 인터페이스의 인스턴스를 생성하기 때문에 테스트할 때 인스턴스의 동작을 통해 테스트할 수 있다.

람다를 사용하는 메서드의 동작에 집중

  • 람다의 목표는 정해진 동작을 다른 메서드에서 사용할 수 있도록 하나의 조각으로 캡슐화 하는 것이다.

  • 람다 표현식을 사용하는 메서드의 동작을 테스트 함으로써 람다 내부 구현을 공개하지 않으면서도 람다 표현식을 검증 할 수 있다.

  • 아래와 같이 람다를 적용한 결과가 예상대로인지 테스트하면 된다.

복잡한 람다 개별 메서드로 분할

  • 복잡한 람다 표현식은 테스트코드에서 참조할 수 없으므로, 람다 표현식을 새로운 일반 메서드로 선언하고 메서드 참조할 수 있도록 바꾸어 테스트해야 한다.

고차원 함수 테스트

  • 함수를 입력받는 메서드의 경우 테스트 코드에서 직접 함수를 입력하여 동작을 검증할 수 있다.

  • 함수를 반환하는 메서드의 경우 반환된 함수의 동작을 테스트하여 검증해야 한다.

디버깅

  • 문제가 발생한 코드를 디버깅할 때에는 스택 트레이스와 로깅을 확인해야 한다.

  • 람다는 이름이 없기 때문에 스택 트레이스의 정보를 이해하기 어려울 수 있다.

  • 스트림 파이프라인에서 요소를 처리할 때 peek 메서드로 스트림 파이프라인의 중간 데이터를 로깅할 수 있다.

// 익명 클래스
Runnable r1 = new Runnable() {
    @Override
    public void run() {
        System.out.println("Hello");
    }
};

// 람다
Runnable r2 = () -> System.out.println("Hello");
int a = 10;

Runnable r1 = new Runnable() {
    int a = 20;    
    @Override
    public void run() {
        System.out.println("Hello");
    }
};

Runnable r2 = () -> {
    int a = 20; // compile error
    System.out.println("Hello");
};
interface Task {
    public void execute();
}

public static void doSomeThing(Runnable r) {
    r.run();
}

public static void doSomeThing(Task t) {
    t.execute();
}

doSomeThing(() -> System.out.println("do")); // 어떤 것이 실행되어야 하는지 알 수 없다. 
doSomeThing((Task)() -> System.out.println("do")); 
// 람다
Map<CaloricLevel, List<Dish>> dishByCaloricLevel = menu.stream()
                .collect(groupingBy(dish -> {
                    if (dish.getCalories() <= 400) return CaloricLevel.DIET;
                    else if (dish.getCalories() <= 700) return CaloricLevel.NORMAL;
                    else return CaloricLevel.FAT;
                }));

// 메서드 참조
Map<CaloricLevel, List<Dish>> dishByCaloricLevel = menu.stream()
                .collect(groupingBy(Dish::getCaloricLevel));

public class Dish {
    // ...
    public CaloricLevel getCaloricLevel() {
        if (this.calories <= 400) return CaloricLevel.DIET;
        else if (this.calories <= 700) return CaloricLevel.NORMAL;
        else return CaloricLevel.FAT;
    }
}
// 람다
inventory.sort((Apple a1, Apple a2) -> a1. getWeight().compareTo(a2.getWeight()));

// 메서드 참조
inventory.sort(comparing(Apple::getWeight))
List<String> dishNames = new ArrayList<>();
for (Dish dish : menu) {
  if (dish.getCalories() > 300) {
    dishNames.add(dish.getName());
  }
}

menu.parallelStream()
  .filter(d -> d.getCalories() > 300)
  .map(Dish::getName)
  .collect(toList());
// 1단계: 직접 로그 객체의 상태를 확인한 후 메시지를 생성해 로깅
if (logger.isLoggable(Log.FINER)) {
  logger.finer("Problem: " + generateDiagnostic());
}

// 2단계: log 메서드 내부에서 로그 객체의 상태를 확인하고 메세지를 로깅
logger.log(Level.FINER, "Problem: " + generateDiagnostic());

// 3단계: log 메서드 내부에서 로그 객체의 상태를 확인하고 적합한 상황에만 람다를 통해 메세지를 생성해 로깅
logger.log(Level.FINER, () -> "Problem: " + generateDiagnostic());
String oneLine = processFile((BufferedReader b) -> b.readLine()); // 람다 전달
String twoLine = processFile((BufferedReader b) -> b.readLine() + b.readLine()); // 다른 람다 전달

public static String processLine(BufferedReaderProcessor p) throws IOException {
  try (BufferdReader br = new BufferedReader(new FileReader("file.txt"))) {
    return p.process(br); // 인수로 전달된 BufferedReaderProcessor 실행
  }
}

public interface BufferedReaderProcessor {
  String process(BufferedReader b) throws IOException;
}
@FunctionalInterface
public interface ValidationStrategy {
    boolean execute(String s);
}

public class Validator {
    private final ValidationStrategy validationStrategy;

    public Validator(ValidationStrategy validationStrategy) {
        this.validationStrategy = validationStrategy;
    }
    
    public boolean validate(String s) {
        return validationStrategy.execute(s);
    }
}

// 람다로 원하는 검증 방식 주입
Validator lowerCaseValidator = new Validator((String s) -> s.matches("[a-z]+"));
lowerCaseValidator.validate("bbbb");

Validator numericValidator = new Validator((String s) -> s.matches("\d+"));
numericValidator.validate("1234");
abstract class OnlineBanking {
    public void processCustomer(int id) {
        Customer c = Database.getCustomerWithId(id);
        makeCustomerHappy.accept(c);
    }
    
    abstract void makeCustomerHappy(Customer c);
}
abstract class OnlineBanking {
    public void processCustomer(int id, Consumer<Customer> makeCustomerHappy) {
        Customer c = Database.getCustomerWithId(id);
        makeCustomerHappy.accept(c);
    }
}

new OnlineBanking().processCustomer(1337, (Customer c) -> print("hello" + c.getName()));
interface Observer {
  void notify(String tweet);
}

public class NyTimes implements NotiObserver {
    @Override
    public void notify(String tweet) {
        if (tweet != null && tweet.contains("monety")) {
            System.out.println("Breaking news in NY ! " + tweet);
        }
    }
}

public class Guardian implements NotiObserver {
    @Override
    public void notify(String tweet) {
        if (tweet != null && tweet.contains("queen")) {
            System.out.println("Yet more new from London .. " + tweet);
        }
    }
}

public interface NotiSubject {
    void registerObserver(NotiObserver o);
    void notifyObservers(String tweet);
}

public class Feed implements NotiSubject {
    private final List<NotiObserver> observers = new ArrayList<>();
    @Override
    public void registerObserver(NotiObserver o) {
        observers.add(o);
    }

    @Override
    public void notifyObservers(String tweet) {
        observers.forEach(o -> o.notify(tweet));
    }
}

Feed f = new Feed();
f.registerObserver(new NyTimes());
f.registerObserver(new Guardian());
f.notifyObservers("The Queen ...")
feed.registerObserver((String tweet) -> {
    if(tweet != null && tweet.contains("money")) {
        System.out.println("Breaking news in NY ! " + tweet);
    }
});
public abstract class ProcessingObject<T> {
    protected ProcessingObject<T> successor;
    
    public void setSuccessor(ProcessingObject<T> successor) {
        this.successor = successor;
    }
    
    public T handle(T input) {
        T r = hadleWork(input);
        if (successor != null) {
            return successor.handle(r);
        }
        return r;
    }
    
    abstract protected T hadleWork(T input);
}

public class HandleTextProcessing extends ProcessingObject<String> {
    @Override
    protected String hadleWork(String input) {
        return "From Raoul, Mario and Alan: " + input;
    }
}

public class SpellCheckProcessing extends ProcessingObject<String> {
    @Override
    protected String hadleWork(String input) {
        return input.replaceAll("labda", "lambda");
    }
}

ProcessingObject<String> p1 = new HandleTextProcessing();
ProcessingObject<String> p2 = new SpellCheckProcessing();
p1.setSuccessor(p2);
String result = p1.handle("Aren't ladbas really sexy?");
// 결과: From Raoul, Mario and Alan: Aren't lambdas really sexy?
UnaryOperator<String> headerProcessing = (String text) -> "From Raoul, Mario and Alan : " + text;
UnaryOperator<String> spellCheckProcessing = (String text) -> text.replaceAll("labda", "lambda");
Function<String, String> pipeline = headerProcessing.andThen(spellCheckProcessing);
pipeline.apply("Aren't ladbas really sexy?");
public class ProductFactory {
    public static Product createProduct(String name) {
        switch (name) {
            case "loan" : return new Loan();
            case "stock" : return new Stock();
            case "bond" : return new Bond();
            default: throw new RuntimeException("");
        }
    }
}

Product p = ProductFactory.createProduct("loan");
final static Map<String, Supplier<Product>> map = new HashMap<>();
static {
  map.put("loan", Loan::new);
  map.put("stock", Stock::new);
  map.put("bond", Bond::new);
}

public static Product createProduct(String name) {
  Supplier<Product> p = map.get(name);
  if (p != null) {
    return p.get();
  }
  throw new IllegalArgumentException("No such product " + name);
}
public class Point {
    public static final Comparator<Point> compareByXAndThenY = comparing(Point::getX).thenComparing(Point::getY);
    // ...
}

@Test
void test() {
    // ...
    assertTrue(Point.compareByXAndThenY.compare(p1, p2) < 0);
}
assertEquals(new Point(15, 10), Point.moveAllPointsRightBy(new Point(5, 10), 10));
List<Integer> nums = Arrays.asList(1, 2, 3, 4);
List<Integer> filtered = filter(nums, i -> i%2 ==0);
assertEquals(Arrays.asList(2, 4), filtered);
numbers.stream()
       .peek(x -> System.out.println("from stream: " + x)
       .map(x -> x + 17)
       .peek(x -> System.out.println("after map: " + x)
       .limit(3)
       // ...
  1. 🏝️자바
  2. 모던 자바 인 액션

9장: 람다를 이용한 리팩토링, 테스팅, 디버깅

Previous8장: 컬렉션 API 개선Next10장: 람다를 이용한 DSL
  • 리팩토링
  • 람다와 디자인 패턴
  • 전략 패턴
  • 템플릿 메서드 패턴
  • 옵저버 패턴
  • 의무 체인 패턴
  • 정적 팩토리 메서드 보완
  • 테스팅
  • 보이는 람다 표현식의 동작 테스트
  • 람다를 사용하는 메서드의 동작에 집중
  • 복잡한 람다 개별 메서드로 분할
  • 고차원 함수 테스트
  • 디버깅