티스토리

영화로운날

검색하기

블로그 홈

영화로운날

glory-day.tistory.com/m

개'발요약'집

구독자: 2

방명록 방문하기

주요 글 목록

[아이템 84] 프로그램의 동작을 스레드 스케줄러에 기대지 말라 [Why] 구체적인 스케줄링 정책은 운영체제마다 다를 수 있다. 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다. [How] 견고하고 빠릿하고 이식성 좋은 프로그램을 작성하는 가장 좋은 방법은 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것이다. 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만들자. 이런 프로그램이라면 스레드 스케줄링 정책이 아주 상이한 시스템에서도 동작이 크게 달라지지 않는다. 여기서 실행 가능한 스레드의 수와 전체 스레드 수는 구분해야 한다. 전체 스레드 수는 훨씬 많을 수 있고, 대기 중인 스레드는 실행 가능하지 않다. 실행 가능한 스레드 수를 적게 유지하는 주요 기법은 각 .. 공감수 1 댓글수 0 2022. 4. 17.
[아이템 83] 지연 초기화는 신중히 사용하라 [배경] 지연 초기화(lazy initialization): 필드의 초기화 시점을 그 값이 처음 필요할 때까지 늦추는 기법 주로 최적화 용도로 쓰이지만, 클래스와 인스턴스 초기화 때 발생하는 위험한 순환 문제를 해결하는 효과도 있다. [Why] 지연 초기화는 양날의 검이다. 클래스 혹은 인스턴스 생성 시의 초기화 비용은 줄지만 그 대신 지연 초기화하는 필드에 접근하는 비용은 커진다. 지연 초기화하려는 필드들 중 결국 초기화가 이뤄지는 비율에 따라, 실제 초기화에 드는 비용에 따라, 초기화된 각 필드를 얼마나 빈번히 호출하느냐에 따라 지연 초기화가 실제로는 성능을 느려지게 할 수도 있다. 지연 초기화가 필요할 때가 있다. 해당 클래스의 인스턴스 중 그 필드를 사용하는 인스턴스의 비율이 낮은 반면, 그 필드.. 공감수 0 댓글수 0 2022. 4. 17.
[아이템 82] 스레드 안전성 수준을 문서화하라 [Why] API 문서에서 동시성에 대한 언급이 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다. 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나(아이템78) 지나치게 한(아이템79) 상태일 것이며, 두 경우 모두 심각한 오류로 이어질 수 있다. 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다. (구현 이슈일 뿐이기 때문) 스레드 안전성에도 수준이 나뉜다. 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 정확히 명시해야 한다. [How] 다음 목록은 스레드 안전성이 높은 순으로 나열한 것이다. 불변(immutable): 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화도 필요 없다.. 공감수 0 댓글수 0 2022. 4. 16.
[아이템 74] 메서드가 던지는 모든 예외를 문서화하라 [Why] 공통 상위 클래스 하나로 뭉뚱그려 선언하면, 메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못할뿐더러, 같은 맥락에서 발생할 여지가 있는 다른 예외들까지 삼켜버릴 수 있어 API 사용성을 크게 떨어뜨린다. 자신이 일으킬 수 있는 오류들이 무엇인지 알려주면 프로그래머는 자연스럽게 해당 오류가 나지 않도록 코딩한다. 잘 정비된 비검사 예외 문서는 사실상 그 메서드를 성공적으로 수행하기 위한 전제조건이 된다. 발생 가능한 비검사 예외를 문서로 남기는 일은 인터페이스 메서드에서 특히 중요하다. 이 조건이 인터페이스의 일반 규약에 속하게 되어 그 인터페이스를 구현한 모든 구현체가 일관되게 동작하기 때문이다. [How] 검사 예외는 항상 따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @t.. 공감수 0 댓글수 0 2022. 4. 6.
[아이템 73] 추상화 수준에 맞는 예외를 던지라 [Why] 수행하려는 일과 관련 없어 보이는 예외가 튀어나오면 당황스러울 것이다. 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 일어나는 일이다. 이는 내부 구현 방식을 드러내어 윗 레벨 API를 오염시키기도 한다. [How] 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다. 이를 예외 번역(exception translation)이라 한다. try { ... // 저수준 추상화를 이용한다. } catch (LowerLevelException e) { // 추상화 수준에 맞게 번역한다. throw new HigherLevelException(...); } 예외를 번역할 때, 저수준 예외가 디버깅에 도움이 된다면 예외 연쇄(exception cha.. 공감수 0 댓글수 0 2022. 4. 5.
[아이템 72] 표준 예외를 사용하라 [Why] 표준 예외를 재사용하면 얻는 게 많다. 우리의 API가 다른 사람이 익히고 사용하기 쉬워진다. 많은 프로그래머에게 이미 익숙해진 규약을 그대로 따르기 때문이다. 우리의 API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다는 장점도 크다. 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다. [How] Exception, RuntimeException, Throwable, Error는 직접 재사용하지 말자. 이 예외들은 다른 예외들의 상위 클래스이므로, 즉 여러 성격의 예외들을 포괄하는 클래스이므로 안정적으로 테스트할 수 없다. 예외 주요 쓰임 IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을 때(null은 따.. 공감수 0 댓글수 0 2022. 4. 5.
[아이템 71] 필요 없는 검사 예외 사용은 피하라 [배경] 검사 예외를 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 문제를 프로그래머가 처리하여 안전성을 높이게끔 해준다. [Why] 검사 예외를 과하게 사용하면 쓰기 불편한 API가 된다. 어떤 메서드가 검사 예외를 던질 수 있다고 선언됐다면, 이를 호출하는 코드에서는 catch 블록을 두어 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야만 한다. 더구나 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바 8부터는 부담이 더욱 커졌다. 검사 예외가 프로그래머에게 지우는 부담은 메서드가 단 하나의 검사 예외만 던질 때가 특히 크다. 이미 다른 검사 예외도 던지는 상황에서 또 다른 검사.. 공감수 0 댓글수 0 2022. 4. 1.
[아이템 70] 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 [배경] 자바는 문제를 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다. 비검사 throwable은 두 가지로, 런타임 예외와 에러다. 둘 다 동작 측면에서는 다르지 않다. 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 한다. 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다. 이런 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으면 중단된다. [How] 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. 이것이 검사와 비검사 예외를 구분하는 기본 규칙이다. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바.. 공감수 0 댓글수 0 2022. 4. 1.
[아이템 69] 예외는 진짜 예외 상황에만 사용하라 예외는 (그 이름이 말해주듯) 오직 예외 상황에서만 써야 한다. 절대로 일상적인 제어 흐름용으로 쓰여선 안 된다. 표준적이고 쉽게 이해되는 관용구를 사용하고, 성능 개선을 목적으로 과하게 머리를 쓴 기법을 자제하라. 잘 설계된 API라면 클라이언트가 정상적인 제어 흐름으에서 예외를 사용할 일이 없게 해야 한다. 특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드도 함께 제공해야 한다. e.g.) Iterator 인터페이스의 next와 hasNext가 각각 상태 의존적 메서드와 상태 검사 메서드에 해당 별도의 상태 검사 메서드 덕분에 다음과 같은 표준 for 관용구를 사용할 수 있다. (for-each도 내부적으로 hasNext를 사용한다) for (Iterat.. 공감수 0 댓글수 0 2022. 4. 1.
[아이템 68] 일반적으로 통용되는 명명 규칙을 따르라 식별자 타입 예 패키지와 모듈 org.junit.jupiter.api, com.google.common.collect 클래스와 인터페이스 Stream, FutureTask, LinkedHashMap, HttpClient 메서드와 필드 remove, groupingBy, getCrc 상수 필드 MIN_VALUE, NEGATIVE_INFINITY 지역변수 i, denom, houseNum 타입 매개변수 T, E, K, V, X, R, U, V, T1, T2 자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 그중 많은 것이 자바 언어 명세에 기술되어 있다. 자바 명명 규칙은 크게 철자와 문법, 두 범주로 나뉜다. 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다. 이 규칙들은.. 공감수 0 댓글수 0 2022. 3. 31.
[아이템 67] 최적화는 신중히 하라 (맹목적인 어리석음을 포함해) 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다 (심지어 효율을 높이지도 못하면서). - 윌리엄 울프[Wulf] (전체의 97% 정도인) 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. - 도널드 크누스[Knuth] 최적화를 할 때는 다음 두 규칙을 따르라. 첫 번째, 하지 마라. 두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라. - M. A. 잭슨[Jackson] [Why] 구현상의 문제는 나중에 최적화해 해결할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다. [How] 빠른 프로그램보다는.. 공감수 0 댓글수 0 2022. 3. 30.
[아이템 66] 네이티브 메서드는 신중히 사용하라 자바 네이티브 인터페이스(Java Native Interface, JNI)란? 자바 프로그램이 네이티브 메서드를 호출하는 기술 네이티브 메서드란 C나 C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드 전통적으로 네이티브 메서드의 주요 쓰임은 다음 세 가지다. 첫 번째, 레지스트리 같은 플랫폼 특화 기능을 사용한다. 두 번째, 네이티브 코드로 작성된 기존 라이브러리를 사용한다. e.g.) 레거시 데이터를 사용하는 레거시 라이브러리 세 번째, 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영역만 따로 네이티브 언어로 작성한다. [Why] 성능을 개선할 목적으로 네이티브 메서드를 사용하는 것은 거의 권장하지 않는다. 자바 초기 시절(자바 3 전)이라면 이야기가 다르겠지만, JVM은 그동안 엄청난 속도로.. 공감수 0 댓글수 0 2022. 3. 30.
[아이템 65] 리플렉션보다는 인터페이스를 사용하라 리플렉션이란? 리플렉션 기능(java.lang.reflect)을 이용하면 프로그램에서 임의의 클래스에 접근할 수 있다. Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져올 수 있다. Constructor, Method, Field 인스턴스들로는 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있다. Constructor, Method, Field 인스턴스를 이용해 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수도 있다. 단점 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다. 예외 검사의 이점도 누릴 수 없다. 리플렉션 기능을 써서 존재하지 않는(접근할 수 없는) 메서드를 호출하려 .. 공감수 0 댓글수 0 2022. 3. 29.
[아이템 64] 객체는 인터페이스를 사용해 참조하라 [Why] 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해질 것이다. 나중에 구현 클래스를 교체하고자 한다면 그저 새 클래스의 생성자(혹은 다른 정적 팩터리)를 호출해주기만 하면 된다. 변수를 구현 타입으로 선언하면 자칫 프로그램이 컴파일되지 않을 수도 있다. 클라이언트에서 교체 전 구현 클래스에서만 제공하는 메서드를 사용했거나, 교체 전 구현 클래스를 사용해야 하는 다른 메서드에 그 인스턴스를 넘겼다면 새로운 코드에서는 컴파일되지 않을 것이다. [When] 인터페이스에는 없는 특별한 메서드를 제공하는 클래스는 클래스로 참조해야 한다. e.g.) PriorityQueue 클래스는 Queue 인터페이스에는 없는 comparator 메서드를 제공한다. [How] 적합한 인터페이스만 있다.. 공감수 0 댓글수 0 2022. 3. 27.
[아이템 63] 문자열 연결은 느리니 주의하라 [Why] 문자열 연결 연산자로 문자열 n개를 잇는 시간은 n^2에 비례한다. 문자열은 불변(아이템17)이라서 두 문자열을 연결할 경우 양쪽의 내용을 모두 복사해야하므로 성능 저하는 피할 수 없는 결과다. [How] 성능을 포기하고 싶지 않다면 String 대신 StringBuilder를 사용하자. StringBuilder를 전체 결과를 담기에 충분한 크기로 초기화하면 조금 더 빠르다. 공감수 0 댓글수 0 2022. 3. 27.
[아이템 62] 다른 타입이 적절하다면 문자열 사용을 피하라 [배경] 문자열은 워낙 흔하고 자바가 또 잘 지원해주어서 원래 의도하지 않은 용도로도 쓰이는 경향이 있다. [Why] 문자열은 다른 값 타입을 대신하기에 적합하지 않다. 많은 사림이 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 주로 문자열을 사용한다. 하지만 입력받을 데이터가 진짜 문자열일 때만 그렇게 하는 게 좋다. 문자열은 열거 타입을 대신하기에 적합하지 않다. (아이템34) 문자열은 혼합 타입을 대신하기에 적합하지 않다. String compoundKey = className + "#" + i.next(); 이는 단점이 많은 방식이다. 두 요소를 구분해주는 문자 #이 두 요소 중 하나에서 쓰였다면 혼란스러운 결과를 초래한다. 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀.. 공감수 0 댓글수 0 2022. 3. 27.
[아이템 61] 박싱된 기본 타입보다는 기본 타입을 사용하라 [배경] 기본 타입과 박싱된 기본 타입의 주된 차이는 크게 세 가지다. 첫 번째, 기본 타입은 값만 가지고 있으나, 박싱된 기본 타입은 값에 더해 식별성(identity)이란 속성을 갖는다. 두 번째, 기본 타입의 값은 언제나 유효하나, 박싱된 기본 타입은 유효하지 않은 값, 즉 null을 가질 수 있다. 세 번째, 기본 타입이 박싱된 기본 타입보다 시간과 메모리 사용면에서 더 효율적이다. [Why] (같은 객체를 비교하는 게 아니라면) 박싱된 기본 타입에 == 연산자를 사용하면 오류가 일어난다. naturalOrder.compare(new Integer(42), new Integer(42)) 첫 번째 검사인 (i < j)는 잘 작동하지만, 두 번째 검사인 (i == j)에서는 두 '객체 참조'의 식별성.. 공감수 0 댓글수 0 2022. 3. 26.
[아이템 60] 정확한 답이 필요하다면 float와 double은 피하라 [예시] 주머니에 1.03달러가 있었는데 그중 42센트를 썼다고 해보자. System.out.println(1.03 - 0.42); 안타깝게도 이 코드는 0.6100000000000001을 출력한다. 주머니에 1달러가 있었는데 10센트짜리 사탕 9개를 샀다고 해보자. System.out.println(1.00 - 9 * 0.10); 이 코드는 0.09999999999999998을 출력한다. 주머니에는 1달러가 있고, 선반에 10센트, 20센트, 30센트, ... 1달러짜리의 맛있는 사탕이 놓여 있다고 해보자. 10센트짜리부터 하나씩, 살 수 있을 때까지 사보자. 사탕을 몇 개나 살 수 있고, 잔돈은 얼마가 남을까? 결과값을 출력하기 전에 반올림하면 해결되리라 생각할지 모르지만, 반올림을 해도 틀린 답이 .. 공감수 0 댓글수 0 2022. 3. 25.
[아이템 59] 라이브러리를 익히고 사용하라 [Why] "바퀴를 다시 발명하지 마라." static Random rnd = new Random(); static int random(int n) { return Math.abs(rnd.nextInt()) % n; } 괜찮은 듯 보여도 문제를 세 가지나 내포하고 있다. 첫 번째, n이 그리 크지 않은 2의 제곱수라면 얼마 지나지 않아 같은 수열이 반복된다. 두 번째, n이 2의 제곱수가 아니라면 몇몇 숫자가 평균적으로 더 자주 반환된다. n값이 크면 이 현상은 더 두드러진다. 세 번째, 지정한 범위 '바깥'의 수가 종종 튀어나올 수 있다. rnd.nextInt()가 반환한 값을 Math.abs를 이용해 음수가 아닌 정수로 매핑하기 때문이다. nextInt()가 Integer.MIN_VALUE를 반환하면.. 공감수 0 댓글수 0 2022. 3. 25.
[아이템 58] 전통적인 for 문보다는 for-each 문을 사용하라 [Why] 스트림이 제격인 작업이 있고 반복이 제격인 작업이 있다. for (Iterator i = c.iterator(); i.hasNext();) { Element e = i.next(); ... // e로 무언가를 한다. } for (int i=0; i 공감수 0 댓글수 0 2022. 3. 24.
[아이템 57] 지역변수의 범위를 최소화하라 [Why] 지역변수의 유효 범위를 최소로 줄이면 코드 가독성과 유지보수성이 높아지고 오류 가능성은 낮아진다. [How] 1. 지역변수의 범위를 줄이는 가장 강력한 기법은 역시 '가장 처음 쓰일 때 선언하기'다. 사용하려면 멀었는데, 미리 선언부터 해두면 코드가 어수선해져 가독성이 떨어진다. 변수를 실제로 사용하는 시점엔 타입과 초깃값이 기억나지 않을 수도 있다. 2. 거의 모든 지역변수는 선언과 동시에 초기화해야 한다. 초기화에 필요한 정보가 충분하지 않다면 충분해질 때까지 선언을 미뤄야 한다. try-catch문은 이 규칙에서 예외다. 변수를 초기화하는 표현식에서 검사 예외를 던질 가능성이 있다면 try 블록 안에서 초기화해야 한다. (그렇지 않으면 예외가 블록을 넘어 메서드에까지 전파된다) 변수 값을.. 공감수 0 댓글수 0 2022. 3. 24.
[아이템 55] 옵셔널 반환은 신중히 하라 [배경] 자바 8 전에는 메서드가 특정 조건에서 값을 반환할 수 없을 때 취할 수 있는 선택지가 두 가지였다. 첫 번째는, 예외를 던지는 것이었다. 하지만 예외는 진짜 예외적인 상황에서만 사용해야 한다.(아이템69) 또한 예외를 생성할 때 스택 추적 전체를 캡처하므로 비용도 만만치 않다. 두 번째는, null을 반환하는 것이었다. 하지만 null을 반환할 수 있는 메서드를 호출할 때는 별도의 null 처리 코드를 추가해야 한다. 자바 8로 올라가면서 또 하나의 선택지가 생겼다. 그 주인공인 Optional는 null이 아닌 T 타입 참조를 하나 담거나, 혹은 아무것도 담지 않을 수 있다. 아무것도 담지 않은 옵셔널은 '비었다'고 말한다. 반대로 어떤 값을 담은 옵셔널은 '비지 않았다'고 한다. 옵셔널은 .. 공감수 0 댓글수 0 2022. 3. 18.
[아이템 54] null이 아닌, 빈 컬렉션이나 배열을 반환하라 [Why] private final List cheesesInStock = ...; /** * @return 매장 안의 모든 치즈 목록을 반환한다. * 단, 재고가 하나도 없다면 null을 반환한다. */ public List getCheeses() { return cheesesInStock.isEmpty() ? null : new ArrayList(cheesesInStock); } List cheeses = shop.getCheeses(); if (cheeses != null && cheeses.contains(Cheese.STILTON)) { System.out.println("좋았어, 바로 그거야."); } 컬렉션이나 배열 같은 컨테이너가 비었을 때 null을 반환하는 메서드를 사용할 때면 항상 방.. 공감수 0 댓글수 0 2022. 3. 17.
[아이템 53] 가변인수는 신중히 사용하라 ※ 가변인수(varargs) 메서드는 명시한 타입의 인수를 0개 이상 받을 수 있다. 가변인수 메서드를 호출하면, 먼저 인수의 개수와 길이가 같은 배열을 만들고 인수들을 이 배열에 저장하여 가변인수 메서드에 건네준다. 인수 개수는 런타임에 (자동 생성된) 배열의 길이로 알 수 있다. ※ printf는 가변인수와 한 묶음으로 자바에 도입되었고, 이때 핵심 리플렉션 기능(아이템65)도 재정비되었다. printf와 리플렉션 모두 가변인수 덕을 톡톡히 보고 있다. [Why] 인수가 1개 이상이어야 할 때도 있다. static int min(int... args) { if (args.length == 0) { throw new IllegalArgumentException("인수가 1개 이상 필요합니다."); } .. 공감수 0 댓글수 0 2022. 3. 17.
[아이템 52] 다중정의는 신중히 사용하라 [Why] public class CollectionClassifier { public static String classify(Set s) { return "집합"; } public static String classify(List lst) { return "리스트"; } public static String classify(Collection c) { return "그 외"; } public static void main(String[] args) { Collections[] collections = { new HashSet(), new ArrayList(), new HashMap().values() }; for (Collection c : collections) { System.out.println.. 공감수 0 댓글수 0 2022. 3. 15.
[아이템 51] 메서드 시그니처를 신중히 설계하라 ※ API 설계 요령을 설명한다. 1. 메서드 이름을 신중히 짓자. 항상 표준 명명 규칙(아이템68)을 따라야 한다. 이해할 수 있고, 같은 패키지에 속한 다른 이름들과 일관되게 짓는 게 최우선 목표다. 그 다음 목표는 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것이다. 긴 이름은 피하자. 애매하면 자바 라이브러리의 API 가이드를 참조하자. 2. 편의 메서드를 너무 많이 만들지 말자. 메서드가 너무 많은 클래스는 익히고, 사용하고, 문서화하고, 테스트하고, 유지보수하기 어렵다. (인터페이스도 마찬가지) 3. 매개변수 목록은 짧게 유지하자. 4개 이하가 좋다. 같은 타입의 매개변수 여러 개가 연달아 나오는 경우가 특히 해롭다. 순서를 기억하기 어려울뿐더러, 실수로 순서를 바꿔 입력해도 그대로 .. 공감수 0 댓글수 0 2022. 3. 13.
[아이템 50] 적시에 방어적 복사본을 만들라 [Why] 자바는 안전한 언어다. 하지만 아무리 자바라 해도 다른 클래스로부터의 침범을 아무런 노력 없이 다 막을 수 있는 건 아니다. 그러니 클라이언트가 여러분의 불변식을 깨뜨리려 혈안이 되어 있다고 가정하고 방어적으로 프로그래밍해야 한다. public final class Period { private final Date start; private final Date end; /** * @param start 시작 시각 * @param end 종료 시각; 시작 시각보다 뒤여야 한다. * @throws IllegalArgumentException 시작 시각이 종료 시각보다 늦을 때 발생한다. * @throws NullPointerException start나 end가 null이면 발생한다. */ pub.. 공감수 0 댓글수 0 2022. 3. 11.
[아이템 49] 매개변수가 유효한지 검사하라 [Why] 메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다. 매개변수 검사를 제대로 하지 못하면 실패 원자성(failure atomicity, 아이템76)을 어기는 결과를 낳을 수 있다. 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다. 더 나쁜 상황은, 메서드가 잘 수행되지만 잘못된 결과를 반환할 때다. 이보다 더 나쁜 상황은, 메서드는 문제없이 수행됐지만 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 때다. [When] 메서드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 한다. 입력받은 int 배열의 List 뷰.. 공감수 0 댓글수 0 2022. 3. 11.
[아이템 48] 스트림 병렬화는 주의해서 적용하라 [배경] 동시성 프로그래밍 측면에서 자바는 항상 앞서갔다. 1996년, 첫 릴리스부터 스레드, 동기화, wait/notify를 지원했다. 자바 5부터는 동시성 컬렉션인 java.util.concurrent 라이브러리와 실행자(Executor) 프레임워크를 지원했다. 자바 7부터는 고성능 병렬 분해(parallel decom-position) 프레임워크인 포크-조인(fork-join) 패키지를 추가했다. 자바 8부터는 parallel 메서드만 한 번 호출하면 파이프라인을 병렬 실행할 수 있는 스트림을 지원했다. [Why] 동시성 프로그래밍을 할 때는 안전성(safety)과 응답 가능(liveness) 상태를 유지하기 위해 애써야 하는데, 병렬 스트림 파이프라인 프로그래밍에서도 다를 바 없다. public .. 공감수 0 댓글수 0 2022. 3. 10.
[아이템 47] 반환 타입으로는 스트림보다 컬렉션이 낫다 [배경] 원소 시퀀스, 즉 일련의 원소를 반환하는 메서드는 수없이 많다. 자바 7까지는 이런 메서드의 반환 타입으로 컬렉션 인터페이스, Iterable, 배열을 썼다. 그런데 자바 8이 스트림이라는 개념을 들고 오면서 반환 타입의 선택이 아주 복잡해졌다. 스트림은 반복(iteration)을 지원하지 않는다. 따라서 스트림과 반복을 알맞게 조합해야 좋은 코드가 나온다. 사실 Stream 인터페이스는 Iterable 인터페이스가 정의한 추상 메서드를 전부 포함할 뿐만 아니라, Iterable 인터페이스가 정의한 방식대로 동작한다. 그럼에도 for-each로 스트림을 반복할 수 없는 까닭은 바로 Stream이 Iterable을 확장(extend)하지 않아서다. 어댑터를 사용하면 반환값의 Stream → Ite.. 공감수 0 댓글수 0 2022. 3. 9.

문의안내

티스토리
로그인
고객센터

티스토리는 카카오에서 사랑을 담아 만듭니다.