kkoon9

운이 없다면 언젠가 다음과 같은 코드와 마주칠지도 모릅니다. try { int i = 0; while(true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e) {} 무슨 일을 하는 코드인지 모를 정도로 직관적이지 않습니다. (아이템 67) 이 코드는 배열의 원소를 순회하는데, 아주 끔찍한 방식으로 하고 있습니다. 무한루프를 돌다가 배열의 끝에 도달해 ArrayIndexOutOfBoundsException이 발생하면 끝을 내는 것이죠. 이 코드를 다음과 같이 표준적인 관용구대로 작성했다면 모든 자바 프로그래머가 곧바로 이해했을 겁니다. for (Mountain m : range) m.climb(); 🤔 그런데 예외를 써서 루프를 종료한 이유..

자바 플랫폼은 명명 규칙이 잘 정립되어 있으며, 그 중 많은 것이 자바 언어 명세에 기술되어 있습니다. 자바의 명명 규칙은 크게 철자와 문법, 두 범주로 나뉩니다. 철자 규칙은 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룹니다. 이 규칙들은 특별한 이유가 없는 한 반드시 따라야 합니다. 이 규칙을 어긴 API는 사용하기 어렵고, 유지보수하기 어렵습니다. 철자 규칙이나 문법 규칙을 어기면 달느 프로그래머들이 그 코드를 읽기 번거로울 뿐 아니라 다른 뜻으로 오해할 수도 있고 그로 인해 오류까지 발생할 수 있습니다. 패키지, 모듈 명명 규칙 패키지와 모듈 이름은 각 요소를 점(.)으로 구분하여 계층적으로 짓습니다. 요소들은 모두 소문자 알파벳 혹은 (드물게) 숫자로 이뤄집니다. 여러분..

🧑🏻‍💻 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다. 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다. 최적화를 할 때는 다음 두 규칙을 따르라. 첫 번째, 하지마라. 두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지마라. 위 격언들은 자바가 탄생하기 20년 전에 나온 것으로, 최적화의 어두운 진실을 이야기해줍니다. 최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽고, 섣불리 진행하면 특히 더 그렇습니다. 빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어를 탄생시키는 것입니다. 성능 때문에 견고한 구조를 희생하지 맙시다. 빠른 프로그램보다는 좋은 프로그램을 작성합시다. 좋은 ..

자바 네이티브 인터페이스(JNI)는 자바 프로그램이 네이티브 메서드를 호출하는 기술입니다. 여기서 네이티브 메서드란 C나 C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드를 말합니다. 전통적으로 네이티브 메서드의 주요 쓰임은 다음 세 가지입니다. 레지스트리 같은 플랫폼 특화 기능을 사용한다. 네이티브 코드로 작성된 기존 라이브러리를 사용한다. 성능 개선을 목적으로 성능에 결정적 영향을 주는 영역만 따로 네이티브 언어로 작성한다. 플랫폼 특화 기능을 활용하려면 네이티브 메서드를 사용해야 합니다. 하지만 자바가 성숙해가면서 (OS 같은) 하부 플랫폼의 기능들을 점차 흡수하고 있습니다. 그래서 네이티브 메서드를 사용할 필요가 계속 줄어들고 있습니다. 예컨대 자바 9은 새로 process API를 추가해 O..

리플렉션 기능(java.lang.reflect)을 이용하면 프로그램에서 임의의 클래스에 접근할 수 있습니다. Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져올 수 있고, 이어서 이 인스턴스들로는 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져올 수 있습니다. 나아가 Constructor, Method, Field 인스턴스를 이용해 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수도 있습니다. 이 인스턴스들을 통해 해당 클래스의 인스턴스를 생성하거나, 메서드를 호출하거나, 필드에 접근할 수 있다는 뜻입니다. 예를 들어 Method.invoke는 어떤 클래스의 어떤 객체가 가진 어떤 메서드라도 호출..

아이템 51에서 매개변수 타입으로 클래스가 아니라 인터페이스를 사용하라고 했습니다. 이 조언을 "객체는 클래스가 아닌 인터페이스로 참조하라"고까지 확장할 수 있습니다. 적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라. 객체의 실제 클래스를 사용해야 할 상황은 '오직' 생성자로 생성할 때뿐입니다. 예를 들어 다음은 Set 인터페이스를 구현한 LinkedHashSet 변수를 선언하는 올바른 모습입니다. // 좋은 예. 인터페이스를 타입으로 사용했다. Set sonSet = new LinkedHashSet(); // 나쁜 예. 클래스를 타입으로 사용했다. LinkedHashSet sonSet = new LinkedHashSet(); 인터페이스를 타입으로 사..

문자열 연결 연산자(+)는 여러 문자열을 하나로 합쳐주는 편리한 수단입니다. 그런데 한 줄짜리 출력값 혹은 작고 크기가 고정된 객체의 문자열 표현을 만들때라면 괜찮지만, 본격적으로 사용하기 시작하면 성능 저하를 감내하기 어렵습니다. 문자열 연결 연산자로 문자열 n개를 잇는 시간은 n의 2승에 비례합니다. 문자열은 불변(아이템 17)이라서 두 문자열을 연결할 경우 양쪽의 내용을 모두 복사해야 하므로 성능 저하는 피할 수 없는 결과로 작용합니다. 예를 들어 다음 메서드는 청구서의 품목(item)을 전부 하나의 문자열로 연결해줍니다. public String statement() { String result = ""; for( int i = 0; i< numItems(); i++) result += lineF..

문자열(String)은 텍스트를 표현하도록 설계되었고, 그 일을 아주 멋지게 해냅니다. 그런데 문자열은 워낙 흔하고 자바가 또 잘 지원해주어 원래 의도하지 않은 용도로도 쓰이는 경향이 있습니다. 이번 아이템에서는 문자열을 쓰지 않아야 할 사례를 다룹니다. 문자열은 다른 값 타입을 대신하기에 적합하지 않습니다. 많은 사람이 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 주로 문자열을 사용합니다. 사뭇 자연스러워 보이지만, 입력받을 데이터가 진짜 문자열일 때만 그렇게 하는 게 좋습니다. 받은 데이터가 수치형이라면, int, float, BigInteger 등 적당한 수치 타입으로 변환해야 합니다. '예/아니오' 질문의 답이라면 적절한 열거 타입이나 boolean으로 변환해야 합니다. 일반화해 이야기..