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

메서드를 생성할 때 쓰기 쉬우며, 오류 가능성이 적은 API를 만드는 방법을 배워보겠습니다.

 

⚠️ 메서드 이름을 신중히 짓자

이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표입니다. 긴 이름을 피하는 게 좋습니다. 애매하면 자바 라이브러리의 API 가이드를 참고하면 좋을 것 같습니다.

 

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

모든 메서드는 각각 자신의 소임을 다해야합니다. 메서드가 너무 많은 클래스는 학습, 사용, 문서화, 유지보수, 테스트하기가 정말 어렵습니다. 인터페이스도 마찬가지입니다. 아주 자주 쓰일 경우에만 별도의 약칭 메서드를 두는 방법도 있습니다. 확신이 서지 않으면 만들지않는 게좋습니다.

 

⚠️ 매개변수 목록은 짧게 유지!

매개변수는 4개 이하가 가장 이상적입니다. 특히 같은 타입의 매개변수 여러 개가 연달아 나오는 경우 정말 이해하기 어렵습니다. 사용자가 매개변수 순서를 기억하기 어려울뿐더러, 실수로 순서를 바꿔 입력해도 컴파일이 되고 실행이 됩니다. 단지 의도와 다르게 동작할 뿐입니다. 

간단하게 매개변수 목록을 줄이는 방법 3가지를 설명하겠습니다.

 

https://applepick.tistory.com/154

가변인수는 신중하게!

위에 내용도 참고 하면 좋을 것 같습니다.

 

첫 번째! 여러 메서드로 쪼개 줍니다. 쪼개진 메서드 각각은 원래 매개변수 목록의 부분집합을 받습니다. 잘못하면 메서드가 많아질 우려가 있지만, 직교 성(독립적)을 높여 오히려 메서드 수를 줄여주는 효과를 볼 수 있습니다. 그렇다고 무한적으로  작게 나누는 게 능사는 아닙니다. 특정 조합의 패턴이 상당히 자주 사용되거나 최적화하여 성능을 크게 개선할 수 있다면 직교 성이 낮아지더라도 편의 기능으로 제공하는 편이 나을 수도 있습니다. 

두 번째! 매개변수 여러 개를 묶어주는 도우미 클래스를 만드는 것입니다. 일반적으로 도우미 클래스는 정적(static) 멤버 클래스로 둡니다. 특히 매개변수 몇 개를 독립된 하나의 개념으로 볼 수 있을 때 추천하는 기법입니다. 예를 들어 카드게임 클래스를 만든다고 가정해보면 메서드를 호출할 때 카드의 숫자와 무늬를 뜻하는 두 매개변수를 항상 같은 순서로 전달할 것입니다. 따라서 이 둘을 묶는 도우미 클래스를 만들어 하나의 매개변수로 주고받으면 API는 물론 클래스 내부 구현도 깔끔해집니다. 

마지막! 객체 생성에 사용한 빌더 패턴을 메서드 호출에 사용하는 것입니다. 이 방법은 매개변수가 많을 때 특히 그중 일부는 생략해도 괜찮을 때 도움이 됩니다. 먼저 모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터 메서드를 호출해 필요한 값을 설정하는 것입니다. 이때 각 세터 메서드는 매개변수 하나 혹은 서로 연관된 몇 개만 설정하게 합니다. 클라이언트는 먼저 필요한 메개변수를 다 설정한 뒤 execute 메서드를 호출해 앞서 설정한 매개변수들의 유효성을 검사합니다. 마지막으로 객체를 넘겨줍니다. 

 

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

매개변수로 적합한 인터페이스가 있다면 그 인터페이스를 직접 사용합니다. 예를 들어 메서드에 HashMap을 넘길일은 없습니다. 대신 Map을 사용합니다. 그러면 HashMap 뿐만 아니라, ConcurrentHashMap, Treemap 등.. 어떠한 Map의 구현체도 인수로 건네줄 수 있습니다. 심지어 아직 존재하지 않은 Map도 넘겨줄 수 있습니다. 인터페이스 대신 클래스를 사용하면 클라이언트에게 특정 구현체만 사용하도록 제한하는 꼴이면서, 혹시라도 입력 데이터가 다른 형태로 존재한다면 명시한 특정 구현체의 객체로 옮겨 담느라 비싼 복사 비용을 치러야 합니다.  

 

ConcurrentHashMap의 간단 설명!

https://applepick.tistory.com/124

[동시성 이슈해결] HashMap보다는 ConcurrentHashMap을 쓰자!