[아이템 51] 메서드 시그니처를 신중히 설계하라.
메서드 이름을 신중히 짓자.
항상 표준 명명 규칙을 따라야합니다. 이름만 보고 이해할 수 있고, 일관성있게 짓는 것이 핵심입니다. 그 다음 목표는 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것입니다. 되도록이면 긴 이름은 피하는 것이 좋습니다. 물론 조직내에 규율이 있다면 그 규율을 지키는 게 우선입니다.
편의 메서드를 너무 만들지 말자.
메서드가 너무 많은 클래스는 파악하고 유지보수 하기도 힘들고 객체지향 SOLID원칙 중 Single Responsiblity Principle에 위반될 수도 있습니다.
매개변수 목록은 짧게 유지하자.
가능한 4개 이하가 좋습니다. 물론 IDE를 이용하면 수고를 덜 수 있지만, 매개변수 수는 적은 쪽이 훨씬 낫습니다. 같은 타입의 매개변수가 여러 개 나오는 경우가 특히 해롭습니다. 실수로 순서를 바꿔서 입력해도 그대로 컴파일은 되고 실행되기 때문에 런타임 시에 오작동이 될 수 있습니다.
다음은 매개변수 목록을 짧게 줄여줄 세 가지 기술입니다.
- 여러 메서드로 쪼갠다. 이 방법은 주의해서 사용합니다. 잘못할 경우 메서드가 너무 많아질 수가 있습니다. 하지만 잘 만들면 직교성을 높여 오히려 메서드 수를 줄여주는 효과도 있습니다.
List
인터페이스가 대표적인 예입니다.subList
메서드와indexOf
메서드를 적절하게 이용하면 지정된 범위의 부분리스트에서의 인덱스를 찾을 수 있습니다. - 두 번째는 매개변수 여러 개를 묶어주는 도우미 클래스를 만드는 것입니다. 일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둡니다.
- 앞서 두 개의 기법을 혼합한 것으로 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다고 보면 됩니다. 먼저 모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터 메서드를 호출해 필ㅇ한 값을 설정하게 하는 것입니다. 매개변수 타입으로는 클래스보다는 인터페이스가 더 낫습니다. 예를들어 메서드에 ArrayList을 사용하지말고 Map을 사용하는 것입니다. 이 방식을 이용하면 유용성을 얻을 수 있습니다.