아이템 51. 메서드 시그니처를 신중히 설계하라

2023. 3. 22. 16:33ㆍ자바

728x90

아이템 51. 메서드 시그니처를 신중히 설계하라

개별 아이템으로 두기 애매한 API 설계 요령들을 모아놓은 챕터이다.

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

메서드 이름은 항상 표준 명명 규칙(아이템 68)을 따라야 한다. 애매한 경우에는 자바 라이브러리의 API 가이드를 참조하는 것이 좋다. 다만 긴 이름은 피하는 것이 좋다.

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

모든 메서드는 각각 자신의 소임을 다해야한다. 메서드가 너무 많은 클래스는 문서화하고, 사용하고 테스트하고, 유지보수 하는 일에 어려움을 겪을 수 밖에 없다. 자신의 각 기능을 완벽히 수행하는 메서드로 제공을 해야하며, 편의 메서드는 확신이 서지 않는 이상 만들지 않는 것이 좋다.

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

최대 4개까지만 전달받는 것을 추천한다. 4개가 넘어가면 매개 변수를 전부 기억하기가 쉽지 않다. 특히나 같은 타입의 매개 변수가 여러 개 연달아 나오는 경우에는 특히 좋지 않다. 사용자가 매개 변수 순서를 기억하기도 어려울 뿐더러 순서를 바꿔 입력하더라도 그대로 동작하기에 의도와 다르게 동작할 수 있다.

😂 휴… 매개변수 줄이기 어려운데 좋은 방법 어디 없나?

저자는 긴 매개변수를 짧게 줄여주는 기술을 세가지 설명해주고 있다.

1. 여러 메서드로 쪼갠다.

쪼개진 메서드는 각각 원래 매개변수 목록의 부분집합을 받는다. 잘못하면 메서드가 너무 많아질 수도 있지만 직교성을 높여 메서드 수를 줄여주는 효과도 있다.

cf) 직교성: 메서드 간의 서로 중복되는 부분이 적어지고 결합도가 낮은 특징

예시

값을 더하고 곱하는 메서드

위의 기능은 값을 더한 뒤 그 더한 값을 곱하는 기능을 담당하고 있다. 이 메서드의 파라미터 개수를 줄이기 위해서는 메서드를 다음과 같이 분리할 수 있다.

개선된 방법

더하는 메서드

곱하는 메서드

호출부

위와 같이 메서드를 분할하는 경우에는 동일한 결과를 얻더라도 파라미터의 개수를 줄일 수 있다.

2. 매개변수 여러 개를 묶어주는 도우미 클래스를 만들어라!

정적 멤버 클래스로 이러한 도우미 클래스를 둘 수 있다.

이러한 방법은 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 방법이다.

예시

예를 들어 카드를 활용한 어떤 메서드가 있다고 가정하자.

기존 코드

기존 코드메서드를 호출할 때 카드의 숫자와 무늬를 뜻하는 두 매개 변수를 항상 같은 순서로 전달한다면 이 둘을 묶는 도우미 클래스를 하나 만들어서 하나의 매개변수로 묶어준다면 API는 물론 클래스 내부 구현도 깔끔하게 만들 수 있다.

개선된 코드

위와 같이 CardNumber나 CardSymbol을 묶은 Card라는 클래스를 만들어서 활용할 수 있다.

3. 빌더 패턴을 사용해라!

모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터 메서드를 호출해 필요한 값을 설정하게 하는 것이다.

매개변수가 많은데, 이 중 일부는 생략 가능한 경우에 이를 사용하는 것이 도움된다.

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

즉, 구현 클래스를 그대로 전달하기 보단 인터페이스를 전달해서 인터페이스에서 약속한 메서드를 호출해가는 방식으로 사용하는 것이 좋다는 의미이다.

😅 무슨 말이야?

클래스를 직접 넘기는 경우

인터페이스를 구현한 클래스를 직접 파라미터로 넘기는 경우에는 위와 같이 동일한 메서드를 호출함에도 불구하고 각 구현 클래스별로 메서드를 정의해야한다.

이는 중복을 유지하기에 일관성도 떨어지고, 유지보수를 어렵게 만드는 단점이 된다.

인터페이스를 파라미터로 넘기는 경우

Piece 인터페이스

위와 같이 Piece 인터페이스가 있고, 해당 인터페이스에 move라는 메서드가 있다면 위의 비효율적인 코드는 아래와 같이 깔끔하게 바꿀 수 있다.

위와 같이 깔끔하게 중복을 제거하여 사용할 수 있다.

boolean보다는 원소 2개까지 열거 타입이 낫다.

boolean으로 넘겨줬을 때 메서드의 이름 상 의미가 명확한 경우를 제외하고는 열거 타입을 사용하는 경우에 의미 전달이 더욱 쉬워진다.

예시

예를 들어 온도계 클래스의 정적 팩토리 메서드가 true로 전달받았을 때는 섭씨 온도로, false를 전달받았을 때는 화씨온도로 온도계를 만든다고 가정해보자.

그때는 위와 같이 boolean 타입으로 값을 전달해야한다.

이때 화씨 온도와 섭씨 온도를 원소로 정의한 열거타입이 있다면 아래와 같이 코드를 개선할 수 있다.

조금 더 가독성이 좋아지는 것을 알 수 있다.

추가적으로 캘빈 온도도 지원해야한다면 확장성이 더 좋아질 수 있다.