Home
Youngho's Devlog
Cancel

[이펙티브자바] 아이템34-int 상수 대신 열거 타입을 사용하라

자바에서의 열거 타입이 없었다면? 아래처럼 정수 상수를 한 묶음으로 선언해서 사용하곤 했다. // 코드 34-1 정수 열거 패턴 - 상당히 취약하다! public static final int APPLE_FUJI = 0; public static final int APPLE_PIPPIN = 1; public static f...

[이펙티브자바] 아이템33-타입 안전 이종 컨테이너를 고려하라

타입 안전 이종 컨테이너 패턴 컨테이너 대신 키를 매개변수화한 다음, 컨테이너에 값을 넣거나 뺄 때 매개변수화한 키를 함께 제공하여 제네릭 타입 시스템이 값의 타입이 키와 같음을 보장해주는 설계 패턴 방식이다. 책에는 위와 같은 설명을 하고 있지만 쉽게 이해되지 않는다. 아래 예제 코드를 통해 살펴보자. public class Favorite...

[이펙티브자바] 아이템32-제네릭과 가변인수를 함께 쓸 때는 신중하라

먼저 가변 인자에 대한 개념이 부족하다면 잘 정리된 여기를 참고하면 좋다. 가변 인수의 허점 가변 인수는 메드 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해는데, 구현 방식에 허점이 있다. 가변 인수를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어진다. 그런데 내부로 감춰야 했을 이 배열을 그만 클라이언트에...

[JPA] HikariCP 설정

HikariCP는 고성능의 JDBC 커넥션 풀 라이브러리이다. SpringBoot는 커넥션 풀 관리를 위해 HikariCP를 사용한다. 이와 관련된 설정 옵션으로 아래 출처 링크를 참고하면 좋다. 참고 및 출처 https://effectivesquid.tistory.com/entry/HikariCP-%EC%84%B8%ED%8C%85%EC%8B%...

[JPA] Connection 누수

사용한 커넥션을 커넥션풀로 다시 반환하지 못하게 되는 현상을 커넥션 누수라 한다. 아래 출처를 통해 다양한 포스팅들을 참고하면 이를 이해하기 쉬울 것이다. 특히! Hibernate 멀티테넌시를 사용한다면 더욱 주의가 필요할 것이다 :) 참고 및 출처 https://velog.io/@rnjsrntkd95/Hikari-CP-%EC%BB%A4%EB%...

[이펙티브자바] 아이템31-한정적 와일드카드를 사용해 API 유연성을 높이라

이전 아이템28에서 이야기했듯 매개변수화 타입은 불공변(invariant)이다. 이를 꼭 기억하자. 즉 서로 다른 타입 Type1과 Type2가 있을 때 List<Type1>은 List<Type2>의 하위 타입도 상위 타입도 아니다. 예를 들어 List<Object>에는 어떤 객체든 ...

[이펙티브자바] 아이템30-이왕이면 제네릭 메서드로 만들자

로 타입으로 이루어진 메서드를 제네릭을 사용하여 변환 아래 예제 코드를 보자. // 코드 30-2 제네릭 메서드 (177쪽) public static Set union(Set s1, Set s2) { Set result = new HashSet<>(s1); result.addAll(s2); return result;...

[이펙티브자바] 아이템29-이왕이면 제네릭 타입으로 만들라

클라이언트에서 직접 형변환해야 하는 타입보단 제네릭 타입이 더 안전하고 쓰기 편하다. 클라이언트에서 불필요한 형변환 없음 훨씬 더 안정적으로 타입을 관리할 수 있다. (런타임 에러가 발생할 확률을 줄일 수 있다.) 사실 제네릭 타입 안에서 리스트를 사욯아는게 항상 가능하지도, 꼭 더 좋은 거도 아니다. 자바가 리스트를 기본 타입으로 ...

[이펙티브자바] 아이템28-배열보다는 리스트를 사용하라

배열과 제네릭 타입의 중요한 두 가지 차이 1) 배열은 공변(covariant)이다. 어려워보이지만 뜻은 간단하다. Sub가 Super의 하위 타입이라면 배열 Sub[]는 배열 Super[]의 하위 타입이 된다.(공변, 즉 함께 변한다는 뜻이다) 반면 제네릭은 불공변(invariant)이다. 즉, 서로 다른 타입 Type1과 Type2가...

[이펙티브자바] 아이템27-비검사 경고를 제거하라

할 수 있는 한 모든 비검사 경고를 제거하라. 모두 제거한다면 그 코드는 타입 안정성이 보장된다. 즉, 런타임에 ClassCastException이 발생할 일이 없고, 개발자가 의도한 대로 잘 동작하리라 확신할 수 있다. 경고를 제거할 순 없지만 타입 안전하다고 확신할 수 있다면 @SupressWarnins(“unchecked”) 애너테이...