오딩이

생성자나 정적 팩토리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는 것이 더 좋다. ⛔ 기존 문제점 정적 팩터리와 생성자에는 똑같은 제약이 하나 있다. 선택적 매개변수가 많을 때 적절히 대응하기 어렵다. 보통 필수 매개변수와 선택 매개변수가 있을 때 필수 매개변수와 선택 매개변수를 1개 받는 생성자, 2개 받는 생성자, 3개 받는 생성자 등의 형태로 선택 매개변수를 전부 다 받는 생성자까지 늘려가는 방식을 사용한다. 하지만 이런 생성자는 매개변수 개수가 많아지면 - 클라이언트 코드를 작성하거나 읽기 어렵고, - 코드를 읽을 때 각 값의 의미가 무엇인지 헷갈리고, - 매개변수가 몇 개인지 주의해서 세어보아야 하고, - 클라이언트가 실수로 매개변수의 순서를 바꿔 건네줘도 컴파일러는 알아채지 못하고, ..

예외 번역과 예외 연쇄를 사용해라. 수행하려는 일과 관련 없어 보이는 예외가 튀어나올 때가 있다. 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 일어난다. 이와 같은 방식은 내부 구현 방식을 드러내어 윗 레벨 API를 오염시키는 문제가 있다. 이와 같은 문제를 피하려면 예외 번역을 사용해야 한다. 🐱‍🚀 예외 번역 (exception translation) 상위 계층에서 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던지는 방법이다. try{ ... // 저수준 추상화를 이용한다. } catch (LowerLevelException e){ // 추상화 수준에 맞게 번역한다. throw new HigherLevelException(...); } 🐱‍💻 예외 연쇄 (exceptio..

상황에 부합한다면 항상 표준 예외를 재사용하자. 예외를 재사용하는 것이 좋으며, 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다. 표준 예외를 재사용하면 얻는 것이 많다. 첫 번째, 여러분의 API가 다른 사람이 익히고 사용하기 쉬워진다. 두 번째, 여러분의 API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다 세 번째, 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다. ⛔ 표준 예외 종류 IllegalArgumentException - 호출자가 인수로 부적절한 값을 넘길 때 던지는 예외 - ex. 반복 횟수를 지정하는 매개변수에 음수를 건낼 때 쓸 수 있다. IllegalStateException - 대상 객체의 상태가 ..

꼭 필요한 곳에만 사용한다면 검사 예외는 프로그램의 안전성을 높여주지만, 남용하면 쓰기 고통스러운 API를 낳는다. 📢 검사 예외 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안정성을 높이게끔 해준다. 물론, 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야만 한다. API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이 정도 부담은 감안할 수 있다. 하지만 둘 다 해당하지 않는다면 비검사 예외를 사용하는 것이..