오딩이

throwable은 사용하지 말자. 자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러를 제공한다. 언제나 100% 명확한 건 아니지만 따르는 지침들이 있다. 📢 검사예외 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 즉, API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한다. 비검사 throwable은 두 가지로, 바로 런타임 예외와 에러다. 둘 다 동작 측면에서는 다르지 않다. 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다. 즉, 프로그램에서 비검사 예외나 에러를 던졌다는 ..

예외는 예외 상황에서 쓸 의도로 설계되었다. 예외는 오직 예외 상황에서만 써야 한다. 🙄 예외는 오직 예외 상황에서만 써야 한다. 예외는 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다. 예외를 사용해서 성능이 좋아지더라도 자바 플랫폼이 꾸준히 개선되고 있으니 최적화로 얻은 상대적인 성능 우위가 오래가지 않을 수 있다. 반면 과하게 영리한 기법에 숨겨진 미묘한 버그의 폐해와 어려워진 유지보수 문제는 계속 이어질 것이다. 😊 잘 설계된 API -> 예외를 사용할 일이 X 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 한다. 특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드도 함께 제공해야 한다. ( Iterator 인터..

표준 명명 규칙을 체화하여 자연스럽게 배어 나오도록 하자 자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 크게 철자와 문법, 두 범주로 나뉜다. 철자 규칙이나 문법 규칙을 어기면 다른 프로그래머들이 그 코드를 읽기 번거로울 뿐 아니라 다른 뜻으로 오해할 수도 있고 그로 인해 오류까지 발생할 수 있다. 🎈 철자 규칙 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다. 철자 규칙을 어긴 API는 사용하기 어렵고, 유지보수하기 어렵다. 패키지와 모듈 각 요소를 점(.)으로 구분하여 계층적으로 짓는다. 요소들은 모두 소문자 알파벳 혹은 숫자로 이뤄진다. 조직 바깥에서도 사용될 패키지라면 인터넷 도메인 이름을 역순으로 사용한다. ex) edu.cmu, com.google, or..

빠른 프로그램을 작성하려 안달하지 말자. 좋은 프로그램을 작성하다 보면 성능은 따라오게 마련이다. ✔ 빠른 프로그램보다는 좋은 프로그램을 작성해야 한다. 성능 때문에 견고한 구조를 희생하지 말자. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 따라서 시스템의 나머지에 영향을 주지 않고도 각 요소를 다시 설계할 수 있다. 프로그램을 완성할 때까지 성능 문제를 아예 무시하라는 뜻은 아니다. 구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다. ✔ 성능을 제한하는 설계를 피하라 개발이 완료된 후에 변경하기 가장 어려운 설계 요소는 바로 컴포넌트끼리 혹은 외..