매개변수가 유효한지 검사하라. 메서드와 생성자는 대부분 특정 조건의 입력 매개변수에 특정 조건을 만족하기를 바랍니다. 만일 잘못된 값이 들어올 경우 보통 예외를 던지거나 컴파일 오류를 잡아내긴 하지만, 오류는 가능한 빨리 잡아내는 게 좋습니다. 그렇지 않으면 감지하기 어려워지고 감지하더라도 찾아내기 힘들어지는 경우도 있습니다. 이러한 경우를 방지하기 위해 매개변수를 미리 확인한다면 즉각적이고 깔끔한 방식으로 예외를 처리할 수 있습니다. 하지만 반드시 메서드를 실행하기 전에 매개변수 유효성 검사를 해야하는 것만은 아닙니다. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때는 다시 고려를 해봐야 합니다....
7장 메서드
이번 장에서는 메서드를 설계할 때 주의할 점들을 살펴본다. 구체적으로는 매개변수와 반환값을 어떻게 처리해야 하는지, 메서드 시그니처는 어떻게 설계해야 하는지, 문서화는 어떻게 해야 하는지를 다룬다. 이번 장의 내용 중 상당 부분은 메서드뿐 아니라 생성자에도 적용된다. 그리고 ‘4장 클래스와 인터페이스’와 마찬가지로 이번 장도 사용성, 견고성, 유연성에 집중할 것이다.
[Item50] 적시에 방어적 복사본을 만들라 이번 아이템에서는 지난 Item17에 다루었던 불변에 대한 주제가 포함되어있습니다. 어떤 객체든 객체의 허락 없이는 외부에서 함부로 내부를 수정하게 하는 일이 없아야 합니다. 하지만 주의를 기울이지 않으면 자신도 모르게 내부를 수정하도록 코드를 짜는 경우가 생길 수 있습니다. 다음은 부주의로 일어날 수 있는 상황을 예시로 든 코드입니다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 public final class Period { private final Date date; private final Date end; public Period(Date start, Date end) { if (start....
[아이템 51] 메서드 시그니처를 신중히 설계하라. 메서드 이름을 신중히 짓자. 항상 표준 명명 규칙을 따라야합니다. 이름만 보고 이해할 수 있고, 일관성있게 짓는 것이 핵심입니다. 그 다음 목표는 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것입니다. 되도록이면 긴 이름은 피하는 것이 좋습니다. 물론 조직내에 규율이 있다면 그 규율을 지키는 게 우선입니다. 편의 메서드를 너무 만들지 말자. 메서드가 너무 많은 클래스는 파악하고 유지보수 하기도 힘들고 객체지향 SOLID원칙 중 Single Responsiblity Principle에 위반될 수도 있습니다....
[아이템 52] 다중정의는 신중히 사용하라. 다음은 컬렉션을 집합, 리스트, 그 외로 구분하고자 만든 프로그램입니다. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 public class CollectionClassifier { public static String classify(Set<?> s) { return "Set"; } public static String classify(List<?> lst) { return "List"; } public static String classify(Collection<?> c) { return "Unknown Collection"; } public static void main(String[] args) { Collection<?...