메소드 이름을 신중히 짓자

메소드 이름은 항상 표준 명명 규칙을 따라야한다. 이해하기 쉽고 같은 패키지에 속한 다른 이름들과 일관되게 짓는게 최우선 목표다. 그 다음은 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것이다. 긴 이름은 피하고 어렵다면 자바라이브러리의 API 가이드를 참조하자.

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

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

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

매개변수가 4개를 넘어가면 기억하기 쉽지않다. 더군다나 같은 타입의 매개변수가 여러개가 나오면 더욱 어려워진다. 매개변수를 많이 받아야할 경우 다음을 참고해보자.

여러 메소드로 쪼갠다

여러 직교성 높은 메소드로 쪼개면 메소드의 재사용성도 높아질 뿐 더러 다양한 활용을 수행할 수 있다. 예를 들어 List의 특정 범위 내에서 특정 원소의 인덱스를 찾아야 한다고 가정하자. 그럼 아마도 다음과 같은 식이 될 것이다. list.rangeBasedIndexOf(start, end, entity); 이런 메소드보단 다음과 같은 메소드가 활용성이 높다. list.getsublist(start, end); sublist.indexOf(entity); 결과적으로 강함과 유연함이 절묘하게 균형을 이룬 API가 탄생한다.

도우미 클래스를 작성한다

매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 사용할 수 있는 방법이다. 도우미 클래스를 통해 독립된 개념을 가진 매개변수를 받는다면 내부 구현도 깔끔해진다.

빌더 패턴을 고려하자

빌더 패턴은 생성시에 몇몇 개의 필요없는 매개변수가 있을 때 유용하게 사용할 수 있다.

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

매개변수로는 인터페이스를 사용하자. 그렇다면 어떤 구현체든 이 메소드를 통해서 넘길 수 있다. 반드시 해당 구현체로 복사하느라 생기는 비용을 없애주는 것이며 또한 아직 구현하지 않은 구현체를 받을 수 있다. 메소드는 범용성 있게 설계해야 한다.

boolean 보다는 enum이 낫다

boolean으로만 받아야 의미가 명확해지는 경우를 제외하곤 enum을 사용하자. 나중에 선택지를 추가하기도 더 쉽다. 예를 들어 온도를 표현하는 enum을 생각해보자.

public enum TemperatureScale {
	FAHERNHEIT, CELSIUS;
}

의미가 명확해진다. 또한 여기에 켈빈온도도 지원해야 한다면 간단히 변경할 수 있다.