[Effective Java 규칙40] 메서드 시그니처는 신중하게 설계하라

[Effective Java 규칙40] 메서드 시그니처는 신중하게 설계하라

Effective Java 2/E 책과 구글링을 통해 내용을 정리하고 개인적인 견해가 포함된 글입니다.

이번 챕터는 알지만 잘 지켜지지 않는 내용인 것 같다.

메서드 이름은 신중하게 골라라.

모든 이름은 네이밍 컨벤션을 따라야하고, 이해하기 쉬우면서도 같은 패키지 안의 다른 이름들과 일관성이 있어야 한다.

편의 메서드 ( convenience method ) 를 제공하는데 너무 힘쓰지 마라.

모든 메서드는 맡은 일이 명확하고 거기에 충실해야 한다. 클래스에 메서드가 너무 많으면 학습, 사용, 테스트, 유지보수 등의 모든 측면에서 어렵다. 인터페이스의 경우에는 메서드가 많으면 문제가 두 배는 더 심각하다. 구현하는 사람에게도, 사용자에게도 그렇다. 클래스나 인터페이스가 수행해야 하는 동작 각각에 대해서 기능적으로 완전한 메서드를 제공해야 한다.

인자 리스트를 길게 만들지 마라. 되도록 4개 이하가 되도록 애써야 한다. 대부분 프로그래머들은 인자 리스트가 길어지면 재대로 기억하지 못하고 API 문서를 봐야지만 사용할 수 있다. 최신 IDE를 사용하면 쉽게 사용할 수도 있겠지만 가능한 짧게 써야 한다.

특히나 자료형이 같은 인자들이 길게 연결된 인자 리스트는 더 위험하다. 순서를 착각할 뿐만 아니라 여전히 컴파일되고 예상치 못한 결과가 발생할 수 있기 때문이다.

긴 인자 리스트를 짧게 줄이는 방법은 1. 하나의 메서드를 여러 메서드로 나누는 것이다.  2. 헬퍼 클래스를 만들어 인자들을 그룹별로 나누는 것이다. 보통 헬퍼 클래스는 static 멤버 클래스이다. 3. 빌더 패턴을 고쳐서 객체 생성 대신 메서드 호출에 적용하는 것이다. 

인자의 자료형으로는 클래스보다 인터페이스가 좋다. 인자를 정의하기에 적합한 인터페이스가 있다면, 인터페이스를 구현하는 클래스 대신에 그 인터페이스를 인자 자료형으로 쓰자. 예를들어 HashMap을 인자로 받지말고 Map을 인자로 받으라는 말이다. Map을 인자로 받으면 Hashtable, HashMap, TreeMap, TreeMap의 하위 자료형 등을 받을 수 있게 된다.

인자 자료형으로 boolean을 쓰는 것보다, 원소가 2개인 enum 자료형을 쓰는 것이 좋다. 그러면 좀 더 읽기 편한 코드가 만들어진다.