JVM/Java

🎯 Goals WildCard 가 왜 필요한지 안다. 언제 Generic 을 쓸지 안다. 언제 wildcard 를 쓸지 안다. Java 의 다양한 컬렉션을 사용하거나 라이브러리를 만들다보면 제네릭을 자주 사용하게 된다. 이 때 `?` 로 표현되는 와일드카드도 심심치 않게 보게 되는데, 이 두녀석의 역할과 용례를 알아보자. WildCard 예제: 와일드 카드는 왜 나왔나? class ShapeTest { void drawAll(List shapeList) { for (Shape shape : shapeList) { shape.draw(); } } @DisplayName("Could not print all shapes with collection type hierarchy") @Test void drawA..

거짓 중복 발생 사례 상품의 정가를 나타내는 Regular Price 를 정의해봅시다. public class RegularPrice { private static final int MIN_AMOUNT = 0; private final int value; RegularPrice(final int amount) { if (amount < MIN_AMOUNT) throw new IllegalArgumentException("가격은 0원 이상이어야 합니다."); this.value = amount; } } 일반 할인, 여름 할인을 책임지는 클래스를 정의해봅시다. @Getter public class RegularDiscountedPrice { private static final int MIN_AMOUNT =..

TL;DR; 무적권 .eqauls() 대신 ==을 써라. Pizza.java @Getter @NoArgsConstructor @AllArgsConstructor public class Pizza { // == 을 쓰면 좋은 이유 // getStatus() 랑 PizzaStatus 값(평가값)이 실제로 같다 하더라도 타입은 다르기 때문에 // compile error 가 발생해야한다. // 이를 피하기위해 .equals() 대신 == 을 쓴다. // Q. enum 에 string 값을 삽입할 수 있는가? private PizzaStatus status; private PizzaColor color; public enum PizzaColor { GREEN, RED, BLUE } public enum Pizz..

Stream 은 왜 만들어졌나? Java , Kotlin 은 List, Set, Array 등 다양한 Collection 을 제공한다. Collection API 와 Iterate 방식은 표준화 되었지만 각 클래스는 같은 기능을 하는 메소드가 중복 정의되어 있다. List 를 정렬하는 방법만 해도 쉽게 2가지를 떠올릴 수 있다. List.sort Collection.sort 리스트 정렬 public class JavaStreamTest { @DisplayName("Sort list with two way ") @Test void forLoop() { List nums = Arrays.asList(5, 4, 3, 2, 1); nums.sort(new Comparator() { @Override public..

개요 SpringBoot 를 사용하지 않는 프로젝트로 환경 설정 값을 yaml 에 지정하고 싶었다. 따라서 순수 Java code 로 `application.yaml` 을 로드할 필요가 있었다. 방법 SnakeYaml + Map 방식 간단한 yaml 은 주로 아래와 같은 코드 스니펫으로 Map을 사용해서 파싱할 수 있다. @Test public void whenLoadYAML_thenLoadCorrectImplicitTypes() { Yaml yaml = new Yaml(); Map document = yaml.load("3.0: 2018-07-22"); assertNotNull(document); assertEquals(1, document.size()); assertTrue(document.conta..

Layered Architecture 개발 중이라면 Presentation - Business Layer 의 Request DTO의 분리를 고려하라. 공통의 Request DTO 사용시 문제점 Controller, Service 모두 같은 RequestDTO 를 쓰면 다음과 같은 문제가 발생한다. 1. Controller 의 Validation annotation 을 Service 가 그대로 달고간다. 2. DTO에 의해 Controller Business Layer 간 의존성이 생긴다. => Controller 및 Request DTO 추가 또는 변경시 Service Layer 가 영향을 받는다. 다이어그램으로 도식화하여 표현해보겠다. 만약, API Spec 이 확장된다면 어떻게 될까? DTO 분리 예..