item 51 leekyunghee - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

메서드 시그니처를 신중히 설계하라

• API 설계 요령
• 요령을 잘 활용하면 배우기 쉽고, 쓰기 쉽고, 오류 가능성이 적은 API를 만들 수 있을 것이다.

메서드 이름을 신중히 짓자.

• 항상 표준 명명 규칙(아이템 68-일반적으로 통용되는 명명규칙을 따르라)
• 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름으 다룬다.
• 메서드와 필드 이름은 첫글자는 소문자
• 상수 필드는 대문자 (단어 사이는 밑줄로 구분)

static final VALUES

• 지역변수에도 다른 멤버와 비슷한 명명 규칙, 약어를 써도 좋다. 약어를 써도 그 변수가 사용되는 문맥에서 의미를 쉽게 유추할 수 있기 때문

입력 매개변수도 지역변수의 하나다. 하지만 메서드 설명 문서에까지 등장하는 만큼 지역변수보다는 신경을 써야한다.

• 타입 매개변수의 이름은 보통 한 문자로 표현한다.

임의의 타입엔 T, 컬렉션 원소의 타입은 E, 맵의 키와 값에는 K와 V를 예외에는 X를, 메서드의 반환 타입에는 R

편의 메서드를 너무 많이 만들지 말자.

• 모든 메서드는 각자 자신의 소임을 다해야한다.
• 메서드가 너무 많은 클래스는 익히고 사용하고 문서화하고 테스트하고 유지보수하기 어렵다. (인터페이스도 마찬가지)

매개변수 목록은 짧게 유지하자.

• 4개 이하가 좋다.
• 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 해롭다.
• 사용자가 순서를 기억하기 어려우며 실수로 순서를 바꿔 입력해도 그대로 컴파일되고 실행된다.

매개변수 수를 줄여주는 기술 3가지

• 여러 메서드로 쪼갠다. 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받는다.
• 매개변수 여러 개를 묶어주는 도우미 클래스를 만든다.
• 위 두가지 기법을 혼합한 것으로 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다.

모든 매개변수가 많을 때 특히 그중 일부는 생략해도 괜찮을 때 도움이 된다. 먼저 모든 매개변수를 하나로 추상화한 객체를 정의하고 클라이언트에서 이 객체의 세터 메서드를 호출해 필여한 값을 설정하게 하는 것이다.

매개변수의 타입으로는 클래스보다는 인터페이스가 더 낫다.

• 매개변수로 적합한 인터페이스가 있다면 (이를 구현한 클래스가 아닌) 그 인터페이스를 직접 사용하자.

예를들어 메서드에 HashMap을 넘길 일은 전혀 없다. 대신 Map을 사용하자.

• 인터페이스 대신 클래스를 사용하면 클라이언트에게 특정 구현체만 사용하도록 제한하는 꼴이며 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현체의 객체로 옮겨 담느라 비싼 복사 비용을 치러야 한다.

boolean 보다는 원소 2개짜리 열거 타입이 낫다. (메서드 이름상 boolean을 받아야 의미가 더 명확할 때는 예외다).

• 열거 타입을 사용하면 코드를 읽고 쓰기가 더 쉬워진다.