java/이펙티브 자바 (14) 썸네일형 리스트형 직렬화 item 87 커스텀 직렬화 형태를 고려해보라. https://donghyeon.dev/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C%EC%9E%90%EB%B0%94/2021/11/06/%EC%BB%A4%EC%8A%A4%ED%85%80-%EC%A7%81%EB%A0%AC%ED%99%94-%ED%98%95%ED%83%9C%EB%A5%BC-%EA%B3%A0%EB%A0%A4%ED%95%B4%EB%B3%B4%EC%9E%90/ item 88 readObject 메서드는 방어적으로 작성하라 https://jithub.tistory.com/377 https://donghyeon.dev/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C%EC%9E%90%EB%B0%94/2021/11/0.. [item 74] 메서드가 던지는 모든 예외를 문서화 하라 각 메서드가 던지는 예외 하나하나를 문서화하는 데 충분한 시간을 쏟아야 한다. 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자. 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자 극단적인 예로 메서드가 Exception이나 Throwable을 던진다고 선언해서는 안 된다. /** * * @return secondField * @throws Throwable * @throws Exception */ public int getSecondField() throws IllegalAccessError { return secondField; } 비검사 예외도 문서화두면 좋다 비검사 예외는 일반적으로 프로그래밍 오류를 뜻하는데 자신이 일으.. [item 73] 추상화 수준에 맞는 예외를 던져라 [item 73] 추상화 수준에 맞는 예외를 던져라 예외 번역 수행하려는 일과 관련 없어 보이는 예외가 발생하면 당황스럽다. 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴대 종종 일어나는 일이다. 이는 내부 구현 방식을 느러내어 윗 레벨 API를 오염시킨다. 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 튀어나와 기존 클라이언트 프로그램을 깨지게 할 수도 있다. 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다. 이를 예외 번역(exception translation)이라 한다. 예외 번역 예시 try { ... // 저수준 추상화를 이용한다. } catch (LowerLevelException e) { /* 추상화 수준에 맞게 번역한다. */ throw.. [item 70] 복구할 수 있는 상황에서는 검사 예외, 프로그래밍 오류에는 런타임 예외를 사용하라 [item 70] 복구할 수 있는 상황에서는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 핵심 정리 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자. 확실하지 않다면 비검사 예외를 던지자. 검사 예외도 아니고, 런타임 예외도 아닌 throwable은 정의하지도 말자. 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자. 핵심 정리 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자. 확실하지 않다면 비검사 예외를 던지자. 검사 예외도 아니고, 런타임 예외도 아닌 throwable은 정의하지도 말자. 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자. 에러 예외 프로그램 종료 프로그램 종료 정상 실행 상태로 못.. [item 69] 예외는 진짜 예외 상황에만 사용하라 [item 69] 예외는 진짜 예외 상황에만 사용하라 핵심정리 예외는 예외 상황에서만 쓸 의도로 설계되었다. 정상적인 제어 흐름에서 사용하면 안된다. 이를 프로그래머에게 강요하는 API를 만들어서도 안된다. for문으로 예외가 발생하면 for문을 끝나도록 작성함. 신박한 아이디어...로 개발하지 마라. 예외를 완전히 잘못 사용한 예 - 따라 하지 말 것! try { int i = 0; while (true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e) { } 무슨 일을 하는 코드인지 알겠는가? 전혀 직관적이지 않다는 사실 하나만으로도 코드를 이렇게 작성하면 안 되는 이유는 충분하다. 이 코드는 배열의 원소를 순회하는데, 아주 끔찍한 방식.. [item 65] 리프렉션보다는 인터페이스를 사용하라 item 65 리프렉션보다는 인터페이스를 사용하라 핵심 정리 리플렉션은 복잡한 특수 시스템을 개발할 때 필요한 강력한 기능이지만, 단점도 많다. 컴파일 타임에는 알 수 없는 클래스를 사용하는 프로그램을 작성한다면 리플렉션을 사용해야 한다. 단, 되도록 객체 생성에만 사용하고, 생성한 객체를 이용할 때는 적절한 인터페이스나 컴파일타임에 알 수 있는 상위 클래스로 형변환해 사용해야 한다. 리플렉션 실행할떄마다 클래스에 대한 정보를 얻을 수 있다. java의 고유한 기능이다. 리플랙션(java.lang.reflect)를 이용하면 컴파일 타임에 알 수 없는 임의의 클래스까지 접근을 할 수 있다. 생성자와 메서드를 가져올 수 있으며 맴버 이름, 필드 타입도 가져올 수 있다. Class 객체가 주어지면 클래스 정보.. Item51~Item52 Item47~Item48 가을 Item49~Item50 인호 Item51~Item52 워니/민이 Item53~Item54 민이/워니 Item55~Item56 진성 Item57~Item58 x(1주차때함) Item59~Item60 제이크 item 51. 메서드 시그니처를 신중히 설계하라 1. 메서드 이름을 신중히 짓자 2. 편의 메서드를 너무 많이 만들지 마라 3. 매개변수 목록은 짧게 유지하자 3-1. 여러 메서드로 쪼개라 3-2. 매개변수 여러개를 묶어주는 도우미 클래스 사용하라 3-3. 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용해라. 4. 매개변수 타입으로 클래스보다 인터페이스가 낫다 1. 메서드 이름을 신중히 짓자 항상 표준 명명 규칙을 따라야 한다. 이해할 수 있고, 같은 패키지에 속한 .. item 43~46 Item35~Item36 제이크 Item37~Item38 인호 Item39~Item40 진성 Item41~Item42 가을 Item43~Item44 민이/워니 Item45~Item46 워니/민이 43. 람다보다는 메서드 참조를 사용하라 핵심 정리 메서드 참조는 람다의 간단명료한 대안이 될 수 있다. 메서드 참조 쪽이 짧고 명확하다면 메서드 참조를 쓰고, 그렇지 않을 때만 람다를 사용하도록 한다. 메서드 참조: http://www.tcpschool.com/java/java_lambda_reference 코딩교육 티씨피스쿨 4차산업혁명, 코딩교육, 소프트웨어교육, 코딩기초, SW코딩, 기초코딩부터 자바 파이썬 등 tcpschool.com 위의 링크를 보면 코드 길이: 메서드 참조 < 람다 람다 map.mer.. 이전 1 2 다음
