Best 아이템

[travelbeeee]

정리

• 각자 맡았던 아이템 중에 제일 유용한 아이템 정리해서 코멘트 남기기

[travelbeeee]

현석

[아이템 2] 생성자에 매개변수가 많다면 빌더를 고려하라.

• ⭐️ 생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는게 더 낫다.
• ❗️빌더 패턴은 실무에서 정말 많이 쓰이고 있는 패턴이라 리마인드

[아이템 16] Public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

• ⭐️ public 클래스는 절대 가변 필드를 직접 노출해서는 안 된다. 불변 필드라도 노출하면 덜 위험하지만 완전히 안심할 수는 없다. Getter 접근자 메서드를 사용하자.
• ❗️모두 알고 있는 기초 지식이지만, 중요한 지식이라 한 번 더 리마인드

[아이템 47] 반환 타입으로는 스트림보다 컬렉션이 낫다

• ⭐️ Stream 인터페이스는 반복(iteration)을 지원하지 않는다. 컬렉션을 반환할 수 있다면 그렇게 하라. 반환 전부터 이미 원소들을 컬렉션에 담아 관리하고 있거나 컬렉션을 하나 더 만들어도 될 정도로 원소 개수가 적다면 ArrayList 같은 표준 컬렉션에 담아 반환하라.
• ❗️실무에서 스트림, 컬렉션을 정말 많이 사용하므로 리마인드

[아이템 62] 다른 타입이 적절하다면 문자열 사용을 피하라

• ⭐️ 문자열을 이용해 다른 값 타입(기본 타입, 열거 타입, 혼합 타입 등등)을 대신하지 마라. 문자열은 Immutable 로 한 번 선언된 String 클래스는 자바 애플리케이션 내부에서 같이 쓰이므로 여러 문제를 초래할 수 있다.

[아이템 72] 표준 예외를 사용하라

• ⭐️ 커스텀 예외보다는 표준 예외를 사용하라. 그러면 다른 개발자들이 이해하기 쉽고, 메모리를 아낄 수 있다.

[kihyun-yang]

기현

[아이템 48] 스트림 병렬화는 주의해서 적용하라

• ⭐️ 실제 실무 코드에서도 스트림을 사용하면서 병렬 스트림으로 데이터를 처리하는 경우가 간혹 있는 것으로 보인다.
• ❗️ 잘 알고 사용하면 parallel 메서드 호출 하나로 코어 수에 비례하는 성능을 만끽할 수 있지만 스트림을 잘못 병렬화하면 성능이 오히려 나빠질 뿐만 아니라 결과 자체가 잘못되거나 예상치 못한 동작이 발생할 수 있으므로 주의하자.

[아이템 55] 옵셔널 반환은 신중히 하라

• ⭐️ 옵셔널을 잘 사용하면 null 체크를 직접하지 않아도 되고, NPE가 발생할 가능성이 있는 값을 직접 다룰 필요가 없기 때문에 실무에서 개발하는데 도움을 받을 수 있을 것.
• ⭐️ orElseGet 같은 경우에는 Optional 내부에 들어갈 값이 null일 경우에만 supplier가 호출되도록 메서드 호출 시점을 지연(Lazy Evaluation)시키는 것이 가능한데, 이를 실무에서 Optional을 사용하는 코드에 잘 적용하면 성능적인 이점을 얻을 수 있을 것이다.
• ❗️다만, 옵셔널 반환에는 성능 저하가 뒤따르니, 성능에 민감한 메서드라면 null을 반환하거나 예외를 던지는 편이 나을 수 있다는 점을 인지하고, 옵셔널을 왠만하면 반환값 이외의 목적으로는 사용하지 말자.

[아이템 57] 지역변수의 범위를 최소화하라

• ⭐️ 실무에서 지역변수의 유효 범위를 최소로 줄이는 방향으로 개발하면 가독성과 유지보수성이 높고 버그 가능성이 낮은 코드를 작성할 수 있으므로 지역변수의 범위를 최소화 하는 방향으로 코드를 작성하자.

[KKambi]

한비

[아이템 31] 한정적 와일드카드를 사용해 API 유연성을 높여라

• ⭐️메소드의 파라미터 타입으로 한정적 와일드카드를 사용하면 유연성을 높일 수 있다. ex) List<? extends/super Number>
• 매개변수화 타입은 불공변이다.
• PECS 공식 (Producer-Extends / Consumer-Super)

[아이템 34] int 상수 대신 열거 타입을 사용하라

• ⭐️컴파일 타임에 어떤 원소가 있는지 알 수 있는 상수 집합이라면 열거 타입을 사용하자.
• 각 상수와 연관된 필드 및 메소드를 추가할 수 있다.
• 상수별 메소드를 다양한 방법으로 구현할 수 있다.
  (추상 메소드 + 오버라이딩 / 함수형 인터페이스 필드 + 람다 / nested enum을 통한 전략 enum 등)

[아이템 64] 객체는 인터페이스를 사용해 참조하라

• ⭐️파라미터, 리턴값, 변수, 필드를 최대한 인터페이스 타입으로 선언한다. 안되면 가장 덜 구체적인 클래스 타입으로!
• 객체의 실제 클래스는 생성자로 인스턴스를 생성할 때만 사용한다.
• 구체적인 클래스에 대한 의존성을 줄여, 구현체를 교체하기 쉬워진다.

[zziri]

지훈

[아이템 37] ordinal 인덱싱 대신 EnumMap을 사용하라

• 비검사 형변환과 Index로 인한 문제를 해결해준다.

[아이템 67] 최적화는 신중히 하라

• 최적화를 할 때는 다음 두 규칙을 따르라.
  • 첫 번째, 하지 마라.
  • 두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라.
• 중요한 것은 구조이다.

[아이템 22] 인터페이스는 타입을 정의하는 용도로만 사용하라

• 인터페이스 구현은 인스턴스가 무엇을 할 수 있는지, 역할을 클라이언트에게 알려주는 것이다.
• 상수 인터페이스보다는 인스턴스화가 불가한 유틸리티 클래스를 구현하자.

[meloncha]

민석

[아이템 6] 불필요한 객체 생성을 피하라

• ⭐️ 실무 코드 작업을 하면서 안내 문구등을 API로 보내줄 때 중복 호출이 많은데, 비슷한 내용의 경우 static 등으로 미리 만들어놓고 재사용하는 것이 최적화에 큰 도움이 된다.
• ❗️ 불필요한 객체 생성은 피하는 것이 좋지만 JVM의 가비지 컬렉터가 성능이 좋아서 프로그램의 명확성과 간결성을 위해 어느정도 타협을 해볼 여지는 있다.

[아이템 12] toString을 항상 재정의하라

• ⭐️ toString 메서드는 모든 하위 클래스에서 이 메서드를 재정의하는 것이 규약이다.
• ⭐️ 디버깅이나 테스트 코드 등에서 데이터를 확인하기에 좋다.
• ❗️롬복의 @ToString 어노테이션이 편해서 자주 사용하는데, JPA의 양방향 매핑시 stackoverflowerror가 날 수 있으니 순환참조가 일어날 경우 주의하자

[아이템 50] 적시에 방어적 복사본을 만들라

• ⭐️ �불변식을 지키지 못하면 데이터의 신뢰가 깨진다.
• ⭐️ �setter는 자제하고, getter에서도 방어적 복사본을 만들어서 반환하자.
• ❗️복사 비용이 너무 크거나 클라이언트가 그 요소를 잘못 수정할 일이 없음을 신뢰하고 있다면 방어적 복사를 안해도 된다.

보너스) [아이템 44] 표준 함수형 인터페이스를 사용하라

• 최근 트렌드인 람다를 활용한 표준 함수형 인터페이스를 익숙하게 사용해보자
• API를 설계할 때 람다를 염두에 두고 설계하자
• 이유 : 코드가 멋있기 때문에 ㅎ

[easyfordev]

이지

[아이템 54] null이 아닌, 빈 컬렉션이나 배열을 반환하라

• 선정 이유 : 실무에서 많이 쓸 것 같다.
• null이 아닌, 빈 배열이나 컬렉션을 반환하라.
• 빈 컬렉션

public List<Cheese> getCheeses() {
	return cheesesInStock.isEmpty() ? Collections.emptyList() : new ArrayList<>(cheesesInStock);
}

• 빈 배열

public List<Cheese> getCheeses() {
 return cheesesInStock.toArray(new Cheese[0]);
}

[아이템3] private 생성자나 열거 타입으로 싱글턴임을 보증하라

• 선정 이유 : 싱글턴을 실제로 잘 안쓰긴 하지만, 디자인 패턴 공부할때 가장 쉽게, 먼저 접하는 것이 싱글턴인것 같다. Java(또는 객체지향 언어)에서 싱글턴 객체 만드는 방법은 이 아이템 하나면 설명할 수 있다.
• 싱글턴 클래스 만드는 방법 3가지
  1. public static 멤버가 final '필드'인 방식
  2. 정적 팩터리 '메서드'를 public static 멤버로 제공
  3. 원소가 하나인 enum 타입을 선언하는 것

[아이템 73] 추상화 수준에 맞는 예외를 던지라

• 선정 이유 : 예외를 알맞게 잘 던지는 것은 실무에서 장기적으로 중요한 것 같다. (로깅, 정확한 에러 감지 등)
• 아래 계층의 예외를 예방하거나 스스로 처리할 수 없고, 그 예외를 상위 계층에 그대로 노출하기 곤란하다면 예외 번역을 사용하라.
• 이때 예외 연쇄를 이용하면, 상위 계층에는 맥락에 어울리는 고수준 예외를 던지면서 근본 원인도 함께 알려주어 오류를 분석하기에 좋다.