티스토리

<T>Story

검색하기

블로그 홈

<T>Story

dev-historys.tistory.com/m

함께자라기 님의 블로그입니다.

구독자: 0

방명록 방문하기

주요 글 목록

item 90 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 ITEM 90 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 Serializable을 구현하기로 결정한 순간 언어의 정상 메커니즘인 생성자 이외의 방법으로 인스턴스 생성이 가능해진다 버그와 보안 문제가 일어날 가능성이 커진다 직렬화 프록시 패턴을 사용하면 버그와 보안 문제가 줄어든다 적절한 프록시 패턴은 별로 복잡하지 않다 바깥 클래스의 논리적 상태를 정밀하게 표현하는 중첩 클래스를 설계해 private static으로 선언한다 이 중첩 클래스가 바로 바깥 클래스의 직렬화 프록시다 중첩 클래스의 생성자는 단 하나여야 하며 바깥 클래스를 매개변수로 받아야 한다 이 생성자는 단순히 인수로 넘어온 인스턴스의 데이터를 복사한다 일관성 검사나 방어적 복사도 필요 없다 설계상 직렬화 프록시의 기본 직렬화 형.. 공감수 0 댓글수 0 2022. 4. 28.
item 89 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거 타입을 사용하라 ITEM 89 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거 타입을 사용하라 바깥에서 생성자를 호출하지 못하게 막는 방식으로 싱글턴을 보장한 코드 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { .. } public void leaveTheBuilding() { .. } } 위 코드는 클래스 선언에 implements Serializable을 추가하면 더이상 싱글턴이 아니게 된다 기본 직렬화를 쓰지 않더라도, 명시적인 readObject를 제공하더라도 소용 없다 어떤 readObject를 사용하든 이클르새가 초기화될 때 만들어진 인스턴스와는 별개인 인스턴스를 반환하게 된다 re.. 공감수 0 댓글수 0 2022. 4. 28.
item 88 readObject 메서드는 방어적으로 작성하라 ITEM 88 readObject 메서드는 방어적으로 작성하라 객체를 역직렬화할 때는 클라이언트가 소유해서는 안 되는 객체 참조를 갖는 필드를 모두 반드시 방어적으로 복사해야 한다 readObject 메서드를 작성할 때는 언제나 public 생성자를 작성하는 자세로 임하자 readObject는 어떤 바이트 스트림이 넘어오더라도 유효한 인스턴스를 만들어내야 한다 바이트 스트림이 진짜 직렬화된 인스턴스라고 가정해서는 안 된다 여기서는 기본 직렬화 형태를 사용한 클래스를 예로 들었지만 커스텀 직렬화를 사용하더라도 모든 문제가 그대로 발생할 수 있다 안전한 readObject 메서드를 작성하는 지침 private이어야 하는 객체 참조 필드는 각 필드가 가리키는 객체를 방어적으로 복사하라 불변 클래스 내의 가변 .. 공감수 0 댓글수 0 2022. 4. 28.
item 87 커스텀 직렬화 형태를 고려해보라 ITEM 87 커스텀 직렬화 형태를 고려해보라 먼저 고민해보고 괜찮다고 판단될 때만 기본 직렬화 형태를 사용하라 기본 직렬화 형태는 유연성, 성능, 정확성 측면에서 신중히 고민한 후 합당할 때만 사용해야 한다 어떤 객체의 기본 직렬화 형태는 그 객체를 루트로 하는 객체 그래프의 물리적 모습을 나름 효율적으로 인코딩 한다 객체가 포함한 데이터와 그 객체부터 시작해 접근할 수 있는 모든 객체를 담아내고 이 객체들이 연결된 위상까지 기술한다 이상적인 직렬화 형태면 물리적인 모습과 독립된 논리적인 모습만 표현해야 한다 객체의 물리적 표현과 논리적 내용이 같다면 기본 직렬화 형태라도 무방하다 사람의 성명을 간략하게 표현한 코드 기본 직렬화 형태를 써도 괜찮다 public class Name implements S.. 공감수 0 댓글수 0 2022. 4. 28.
item 86 Serializable을 구현할지는 신중히 결정하라 ITEM 86 Serializable을 구현할지는 신중히 결정하라 클래스의 인스턴스를 직렬화가 가능하게 하려면 Serializable을 구현하면 된다 쉽게 적용 가능하기 때문에 개발자가 특별히 신경 쓰지 않아도 된다고 생각 할 수 있지만 사실은 훨씬 더 복잡하다 직렬화를 지원하는게 짧게 보면 쉬워 보이지만 길게 보면 아주 값 비싼 일이다 Serializable을 구현하면 릴리스한 뒤에는 수정하기 어렵다 클래스가 Serializable을 구현하면 직렬화된 바이트 스트림 인코딩도 하나의 공개 API가 된다 클래스가 많이 사용되게 되면 그 직렬화 형태도 다른 공개 API 처럼 영원히 지원해야 하는 것이다 커스텀 직렬화 형태를 설계하지 않고 자바의 기본 방식을 사용하면 직렬화 형태는 최소 적용 당시 클래스의 내.. 공감수 0 댓글수 0 2022. 4. 26.
item 85 자바 직렬화의 대안을 찾으라 ITEM 85 자바 직렬화의 대안을 찾으라 직렬화 위험을 회피하는 가장 좋은 방법은 아무것도 역직렬화하지 않는것이다 신뢰할 수 없는 바이트 스트림을 역직렬화 하는게 스스로를 공격에 노출하는 행위다 객체와 바이트 시퀀스를 변환해주는 다른 메커니즘이 많이 있기 때문에 우리가 작성하는 코드에 자바 직렬화를 써야 할 이유가 없다 이 방식들은 자바 직렬화의 여러 위험을 회피하면서 다양한 플랫폼 지원, 우수한 성능, 풍부한 지원 도구, 활발한 커뮤니티와 전문가 집단 등 수많은 이점을 제공한다 이 표현들은 자바 직렬화보다 훨씬 간단하며 임의 객체 그래프를 자동으로 직렬화,역직렬화 하지 않는다 대신 속성-값 쌍의 집합으로 구성된 간단하고 구조화된 데이터 객체를 사용하며 기본타입 몇개와 배열타입만 제공할 뿐이다 위와 같.. 공감수 0 댓글수 0 2022. 4. 26.
item 84 프로그램의 동작을 스레드 스케줄러에 기대지 말라 ITEM 84 프로그램의 동작을 스레드 스케줄러에 기대지 말라 여러 스레드가 실행 중이면 운영체제의 스레드 스케줄러가 어떤 스레드를 얼마나 오래 실행할지 정한다 정상적인 운영체제라면 이 작업을 공정하게 수행하지만 구체적인 스케쥴링 정책은 운영체제마다 다를 수 있다 따라서 잘 작성된 프로그램이라면 이 정책에 좌지우지 돼서는 안 된다 정확성이나 성능이 스레드 스케줄러에 따라 달라지는 프로그램이라면 다른 플랫폼에 이식하기 어렵다 빠르고 견고하며 이식성 좋은 프로그램을 작성하는 가장 좋은 방법은 실행 가능한 스레드의 평균적인 수를 프로세서 수보다 지나치게 많아지지 않도록 하는 것 이렇게 해야 스레드 스케쥴러가 고민할 거리가 줄어든다 실행 준비가 된 스레드들은 맡은 작업을 완료할 때까지 계속 실행되도록 만들자 이.. 공감수 0 댓글수 0 2022. 4. 25.
item 83 지연 초기화는 신중히 사용하라 ITEM 83 지연 초기화는 신중히 사용하라 지연 초기화(lazy initialization)는 필드의 초기화 시점을 그 값이 처음 필요할 때까지 늦추는 기법이다 값이 전혀 쓰이지 않으면 초기화도 결코 일어나지 않는다 이 기법은 정적 필드와 인스턴스 필드 모두에 사용할 수 있다 지연 초기화는 주로 최적화 용도로 쓰이며 클래스와 인스턴스 초기화 때 발생하는 위험한 순환 문제를 해결하는 효과도 있다 다른 모든 최적화와 마찬기로 필요할 때까지는 하지 않는게 좋으며 지연초기화는 양날의 검이다 클래스 혹은 인스턴스 생성시 초기화 비용은 줄지만 그 대신 지연 초기화하는 필드에 접근하는 비용은 커진다 지연 초기화하려는 필드 중 결국 초기화가 이뤄지는 비율, 실제 초기화에 드는 비용, 초기화된 각 필드를 얼마나 빈번히.. 공감수 0 댓글수 0 2022. 4. 25.
item 82 스레드 안정성 수준을 문서화하라 ITEM 82 스레드 안정성 수준을 문서화하라 한 메서드를 여러 스레드가 동시에 호출할 때 그 메서드가 어떻게 동작하느냐는 해당 클래스와 이를 사용하는 클라이언트 사이의 중요한 계약과 같다 API 문서에서 아무런 언급도 없으면 그 클래스 사용자는 나름의 가정을 해야만 한다 만약 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나 지나치게 한 상태일 것이며 두 경우 모두 심각한 오류로 이어질 수 있다 API 문서에 synchronized 한정자가 보이는 메서드는 스레드 안전하다는 이야기가 있다 이건 몇가지 이유로 틀린 이야기이다 자바독이 기본 옵션에서 생성한 API 문서에는 synchronized 한정자가 포함되지 않는다 메서드 선언에 synchronized 한정자를 선언할지는 구현 이슈.. 공감수 0 댓글수 0 2022. 4. 25.
item 81 wait와 notify보다는 동시성 유틸리티를 애용하라 ITEM 81 wait와 notify보다는 동시성 유틸리티를 애용하라 wait와 notifiy는 올바르게 사용하기가 아주 까다로우니 고수준 동시성 유틸리티를 사용하자 java.util.concurrent의 고수준 유틸리티는 세 범주로 나눌 수 있다 실행자 프레임워크, 동시성 컬렉션(concurrent collection), 동기화 장치(synchronizer) 실행자 프레임워크는 item80에서 가볍게 알아 보았고 이번 item에서는 동시성 컬렉션과 동기화 장치를 알아본다 동시성 컬렉션 List, Queue, Map 같은 표준 컬렉션 인터페이스에 동시성을 가미해 구현한 고성능 컬렉션이다 높은 동시성에 도달하기 위해 동기화를 각자의 내부에서 수행한다 동시성 컬렉션에서 동시성을 무시력화하는 건 불가능하며 외.. 공감수 0 댓글수 0 2022. 4. 25.
item 80 스레드보다는 실행자, 태스크, 스트림을 애용하라 ITEM 80 스레드보다는 실행자, 태스크, 스트림을 애용하라 실행자 프레임워크(Executor Framework) 인터페이스 기반의 유연한 태스크 실행 기능 java.util.concurrent 패키지에 담겨있다초판의 코드보다 모든 면에서 뛰어난 작업 큐를 단 한줄로 생성 가능해졌다 ExecutorService exec = Executors.newSingleThreadExecutor(); 이 실행자가 실행할 태스크(작업)를 넘기는 방법이다 exec.execute(runnable); 실행자를 우아하게 종료시키는 방법(이 작업이 실패하면 VM 자체가 종료되지 않는다) exec.shutdown(); 큐를 둘 이상의 스레드가 처리하게 하고 싶다면 간단히 다른 정적 팩터리를 이용하여 다른 종류의 실행자 서비스(.. 공감수 0 댓글수 0 2022. 4. 23.
item 79 과도한 동기화는 피하라 ITEM 79 과도한 동기화는 피하라 과도한 동기화는 성능을 떨어뜨리고 교착상태에 빠뜨리고 예측할 수 없는 동작을 낳기도 한다 응답 불가와 안전 실패를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에 양도하면 안 된다 동기화된 영역 안에서는 재정의할 수 있는 메서드는 호출하면 안된다 클라이언트가 넘겨준 함수 객체를 호출해서도 안된다 동기화된 영역을 포함한 클래스 관점에서는 이런 메서드는 다른 차원에서 온 외계인이다 그 메서드가 무슨 일을 할지 알지 못하며 통제할 수도 없다는 뜻이다 외계인 메서드(alien method)가 하는 일에 따라 동기화된 영역은 예외를 일으키거나 교착상태에 빠지거나 데이터를 훼손할 수도 있다 열린 호출(open call) 동기화 영역 바깥에서 호출되는 외.. 공감수 0 댓글수 0 2022. 4. 23.
item 78 공유 중인 가변 데이터는 동기화해 사용하라 ITEM 78 공유 중인 가변 데이터는 동기화해 사용하라 synchronized 키워드는 해당 메서드나 블록을 한번에 한 스레드씩 수행하도록 보장한다 많은 개발자가 동기화를 배타적 실행 용도로 생각한다 한 스레드가 변경하는 중이라 상태가 일관되지 않은 순간의 객체를 다른 스레드가 보지 못하게 막는 용도로만 생각한다 한 객체가 일관된 상태를 가지고 생성 해당 객체에 접근하는 메서드는 그 객체에 락(lock)을 건다 락을 건 메서드는 객체의 상태를 확인 후 필요하면 수정 즉 객체를 하나의 일관된 상태에서 다른 일관된 상태로 변화시키며 동기화를 제대로 사용하면 어떤 메서드도 이 객체의 상태가 일관되지 않은 순간을 볼 수 없다 동기화 없이는 한 스레드가 만든 변화를 다른 스레드에서 확인하지 못 할 수 있다 동기.. 공감수 0 댓글수 0 2022. 4. 23.
item 77 예외를 무시하지 말라 ITEM 77 예외를 무시하지 말라 예외를 무시하지 말라는 말은 당연한 이야기지만 사람들이 자주 어기고 있는 내용이다 API 설계자가 메서드 선언에 예외를 명시하는 이유는 그 메서드를 사용할 때 적절한 조치를 취해달라는 이야기다 API 설계자가 친절하게 써놓은 내용을 대충 듣지 말자 실제로 예외를 무시하는 일은 매우 쉽게 이루어 진다 // catch 블록을 비워버리면 예외가 무시된다 try { ... } catch (SomeException e){ } 예외는 문제 발생시 대처하는데 아주 중요한 요소인데 catch 블록을 비워두면 예외가 존재할 이유가 없다 비유하자면 화재 경보를 무시하는걸 넘어서 아예 꺼버려 다른 사람들도 화재 상황을 알지 못하게 하는 수준이다 빈 catch 블록을 목격한다면 항상 사이렌.. 공감수 0 댓글수 0 2022. 4. 23.
item 76 가능한 한 실패 원자적으로 만들라 ITEM 76 가능한 한 실패 원자적으로 만들라 실패 원자적(failure-atomic) 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다 메서드를 실패 원자적으로 만드는 방법 가장 간단한 방법은 불변 객체로 설계하는 것 불변 객체의 상태는 생성 시점에 고정되어 절대 변하지 않기 때문에 태생부터 실패 원자적이다 가변 객체를 실패 원자적으로 만드는 방법은 작업 수행에 앞서 매개변수 유효성을 검사하는 것이다 객체의 내부 상태를 변경하기 전에 잠재적 예외의 가능성 대부분을 걸러낼 수 있다 객체의 임시 복사본에서 작업을 수행하고 작업이 성공적으로 완료되면 원래 객체와 교체하는 것 데이터를 임시 자료구조에 저장해 작업하는게 더 빠를 때 적용하기 좋다 작업 도중 발생하는 실패를 가로채는.. 공감수 0 댓글수 0 2022. 4. 23.
item 75 예외의 상세 메시지에 실패 관련 정보를 담으라 ITEM 75 예외의 상세 메시지에 실패 관련 정보를 담으라 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다 스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열이다 보통 예외의 클래스 이름 뒤에 상세 메세지가 붙는 구조다 이런 정보가 실패 원인을 분석해야 하는 개발자나 SRE가 얻을 수 있는 유일한 정보인 경우가 많다 더구나 실패를 재현하기 어렵다면 더 자세한 정보를 얻기가 어렵거나 불가능하다 따라서 예외의 toString 메서드에 실패 원인에 관한 정보를 가능한 많이 담아서 반환 하는게 중요하다 사후분석을 위해 실패 순간의 상황을 정확히 포착해 예외의 상세 메세지에 담아야 한다 실패 순간을 포착하려면 발생한 예외.. 공감수 0 댓글수 0 2022. 4. 22.
item 74 메서드가 던지는 모든 예외를 문서화하라 ITEM 74 메서드가 던지는 모든 예외를 문서화하라 메서드가 던지는 예외는 그 메서드를 올바로 사용하는데 아주 중요한 정보니 예외 하나하나 모두 문서화 하는게 좋다 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화 하자 공통 상위 클래스 하나로 뭉뚱그려 선언 하지 말자 극단적인 예) 메서드가 Exception, Throwable을 던진다고 선언하면 안된다 메서드 사용자에게 각 예외에 대처할 수 있는 힌트를 주지 못한다 같은 맥락에서 발생 가능한 다른 예외까지 삼켜 API 사용성을 떨어뜨린다 이 규칙의 유일한 예외는 오직 JVM만이 호출하는 main 메서드이다 자바 언어가 요구하지는 않지만 비검사 예외도 검사 예외처럼 문서화 해두면 좋다.. 공감수 0 댓글수 0 2022. 4. 22.
item 73 추상화 수준에 맞는 예외를 던져라 ITEM 73 추상화 수준에 맞는 예외를 던져라 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다 그렇지 않으면 수행하려는 일과 관련 없어 보이는 예외가 발생해 내부 구현 방식을 드러내고 윗 레벨 API를 오염시키게 된다 다음 릴리스에서 구현 방식을 바꾸면 다른 예외가 나타나 기존 클라이언트를 깨지게 할 수도 있다 예외 번역 try { ... // 저수준 추상화를 이용한다 } catch (LowerLevelException e) { // 추상화 수준에 맞게 번역한다 throw new HigherLevelException(...); } 다음은 AbstractSequentialList에서 수행하는 예외 번역의 예다 AbstractSequentialList는 List 인터.. 공감수 0 댓글수 0 2022. 4. 22.
item 72 표준 예외를 사용하라 ITEM 72 표준 예외를 사용하라 표준 예외를 재사용하면 얻는게 많다 최고의 장점은 내가 만든 API가 다른 사람이 익히고 사용하기가 쉬워진다 많은 개발자들에게 이미 익숙해져 있는 규약을 따르기 때문 내가 만든 API를 사용한 프로그램도 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다 가장 흔하게 재사용 많이 되는 예외 IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을때 (null 은 따로 NPE 처리) IllegalStateException 객체가 메서드를 수행하기에 적절하지 않은 상태인 경우 NullPointerException null을 허용하지 않는 메서드에 null을 건낸경우 I.. 공감수 0 댓글수 0 2022. 4. 22.
item 71 필요 없는 검사 예외 사용은 피하라 ITEM 71 필요 없는 검사 예외 사용은 피하라 검사 예외를 싫어하는 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 다르게 검사 예외는 발생한 문제를 개발자가 처리해 안정성을 높여준다 하지만 검사 예외를 과하게 쓰면 오히려 쓰기 불편한 API가 된다 어떤 메서드가 검사 예외를 던질 수 있다면 이 메서드를 호출하는 코드에서는 catch 블록을 이용해 그 예외를 붙잡아 처리하거나 더 바깥으로 던져 문제를 전파해야된다 어느쪽이든 API 사용자에게 부담을 주며 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없기 때문에 자바8부터는 더욱 부담이 커졌다 API를 제대로 사용해도 발생할 수 있는 예외거나 개발자가 의미있는 조치.. 공감수 0 댓글수 0 2022. 4. 22.
item 70 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 ITEM 70 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 자바에서 문제 상황을 알리는 타입(throwable) 세 가지 검사 예외 런타임 예외 에러 위 3가지의 사용 시점을 헷갈리는 개발자가 많으니 그에 관련한 지침을 알아보자 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라 검사와 비검사 예외를 구분하는 기본 규칙이다 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다 비검사 throwable은 런타임 예외와 에러 두가지다 둘다 동작 측면에서는 다르지 않으며.. 공감수 0 댓글수 0 2022. 4. 22.
item 69 예외는 진짜 예외 상황에만 사용하라 ITEM 69 예외는 진짜 예외 상황에만 사용하라 운이 없다면 아래와 같은 코드를 마주칠 수도 있다 예외를 완전히 잘못 사용한 예 try { int i=0; while(true) range[i++].climb(); } catch (ArrayIndexOutOfBoundsException e) { } 무슨 일을 하는지 알 수 없는 직관적이지 않은 코드이며 배열의 원소를 아주 끔직한 방법으로 순회하고 있다 무한루프를 돌다가 배열의 끝에 도달해서 Exception이 발생하면 끝을 내는 방식이다 위 코드를 아래처럼 표준적인 관용구로 작성하면 다른 개발자가 바로 이해할 것이다 for (Mountain m : range) m.climb(); 그렇다면 왜 예외를 써서 반복문을 빠져나오게 했을까? 잘못된 추론을 근거로 .. 공감수 0 댓글수 0 2022. 4. 22.
item 68 일반적으로 통용되는 명명 규칙을 따르라 ITEM 68 일반적으로 통용되는 명명 규칙을 따르라 자바 플랫폼은 명명 규칙이 잘 정립되어 있고 그중 많은 것이 자바 언어 명세에 기술되어 있다 자바의 명명 규칙은 크게 철자와 문법으로 나뉜다 철자 규칙이나 문법 규칙을 어기면 다른 개발자들이 코드를 읽기도 번거롭고 잘 못 이해하는 경우도 발생한다 철자 규칙 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다루며 이 규칙들은 특별한 이유가 없으면 반드시 지켜야 한다 이 규칙을 어긴 API는 사용도 어렵고 유지보수도 어렵다 패키지와 모듈 이름은 각 요소를 점(.)으로 구분해서 계층적으로 짓는다 요소들은 모두 소문자 알파벳이나 숫자로 이루어진다 조직 바깥에서도 사용될 패키지는 조직의 도메인 이름을 역순으로 사용한다 ex) edu.cmu, .. 공감수 0 댓글수 0 2022. 4. 22.
item 67 최적화는 신중히 하라 ITEM 67 최적화는 신중히 하라 최적화 격언 세가지 맹목적인 어리석음을 포함해 그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다(심지어 효율을 높이지도 못하면서) 윌리엄 울프 전체의 97% 정도인 자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다 도널드 크누스 최적화를 할 때는 다음 두 규칙을 따르라 첫번째 하지마라 두번째 전문가 한정 아직 하지마라. 다시말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라 M. A. 잭슨 이 격언들은 자바가 탄생하기 20년 전에 나왔으며 최적화의 어두운 진실을 이야기한다 최적화는 좋은 결과보다 안좋은 결과가 나타나기 쉽다 잘못하면 빠르지도 않고 제대로 동작하지도 않으면서 수정이 어려워진다 성능 때문에 견고한 구조를.. 공감수 0 댓글수 0 2022. 4. 22.
item 66 네이티브 메서드는 신중히 사용하라 ITEM 66 네이티브 메서드는 신중히 사용하라 자바 네이티브 인터페이스(Java Native Interface, JNI) 자바 프로그램이 네이티브 메서드를 호출하는 기능이다 네이티브 메서드: C, C++ 같은 네이티브 프로그래밍 언어로 작성한 메서드 전통적으로 네이티브 메서드는 아래 3가지 경우에 주로 사용된다 레지스트리 같은 플랫폼 특화 기능을 사용한다 네이티브 코드로 작성된 기존 라이브러리를 사용한다 레거시 데이터를 사용하는 레거시 라이브러리가 그 예다 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영역만 따로 네이티브 언어로 작성한다 플랫폼 특화 기능을 활용하려면 네이티브 메서드를 사용해야 하지만 자바가 성숙해지며(OS 같은) 하부 플랫폼의 기능을 흡수하고 있다 따라서 네이티브 메서드를 사용할.. 공감수 0 댓글수 0 2022. 4. 21.
item 65 리플렉션보다는 인터페이스를 사용하라 ITEM 65 리플렉션보다는 인터페이스를 사용하라 리플렉션을 쓰면 프로그램에서 임의의 클래스에 접근할 수 있다(java.lang.reflect) Class 객체가 주어지면 그 클래스의 생성자, 메서드, 필드에 해당하는 Constructor, Method, Field 인스턴스를 가져올 수 있다 가져온 인스턴스들로는 그 클래스의 멤버 이름, 필드 타입, 메서드 시그니처 등을 가져 올 수도 있다 Constructor, Method, Field 인스턴스를 이용해 각각에 연결된 실제 생성자, 메서드, 필드를 조작할 수도 있다 이 인스턴스를 이용해서 해당 클래스의 인스턴스를 생성하거나 메서드를 호출하거나 필드에 접근 가능하다는 말이다 ex) Method.invoke는 어떤 클래스의 어떤 객체가 가진 어떤 메서드라도.. 공감수 0 댓글수 0 2022. 4. 21.
item 64 객체는 인터페이스를 사용해 참조하라 ITEM 64 객체는 인터페이스를 사용해 참조하라 적합한 인터페이스만 있다면 매개변수뿐 아니라 반환값, 변수, 필드를 전부 인터페이스 타입으로 선언하라 객체의 실제 클래스를 사용해야 할 상황은 오직 생성자로 생성할 때 뿐이다 Set 인터페이스를 구현한 LinkedHashSet 변수를 선언하는 올바른 모습 //인터페이스를 타입으로 선언한 좋은 예 Set sonSet = new LinkedHashSet(); //클래스를 타입으로 사용한 나쁜 예 LinkedHashSet sonSet = new LinkedHashSet(); 인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해질것이다 구현 클래스를 교체하는 상황이 발생하면 그저 새 클래스의 생성자나 다른 정적 팩터리를 호출해주기만 하면된다첫번째.. 공감수 0 댓글수 0 2022. 4. 21.
item 63 문자열 연결은 느리니 주의하라 ITEM 63 문자열 연결은 느리니 주의하라 문자열 연결 연산자(+)는 여러 문자열을 하나로 합칠때 많이 사용한다 한 줄 짜리 출력값, 작고 크기가 고정된 객체의 문자열 표현을 만드는 경우는 괜찮다 하지만 본격적으로 사용하면 성능 저하를 감내하기가 어렵다 문자열 연결 연산자로 문자열 n개를 잇는 시간은 n²에 비례한다 문자열은 불변이라 두 문자열을 연결하면 양쪽의 내용을 모두 복사하니 성능 저하는 필연적이다 청구서의 품목(item)을 전부 하나의 문자열로 연결하는 코드 문자열 연결을 잘못 사용한 예 public String statement() { String result = ""; for (int i = 0; i < numItems(); i++) { result += lineForItem(i); //문.. 공감수 0 댓글수 0 2022. 4. 21.
item 62 다른 타입이 적절하다면 문자열 사용을 피하라 ITEM 62 다른 타입이 적절하다면 문자열 사용을 피하라 String은 텍스를 표현하도록 설계되었고 설계 의도대로 아주 잘 동작하지만 워낙 흔하고 자바가 잘 지원해주어 원래의 의도와 다른용도로 쓰이는 경우가 많다 문자열을 쓰지 않아야 하는 경우 문자열은 다른 값 타입을 대신하기에 적합하지 않다 많은 경우 파일, 네트워크, 키보드 입력으로부터 데이터를 받을 때 문자열을 사용하는 경우가 많지만 입력받을 데이터가 진짜 문자열인 경우에만 쓰는게 좋다 받은 데이터가 수치형이면 int, float, BigInteger 등 적당한 수치형 타입으로 변환해야 한다 예/아니오 같은 질문의 답이라면 적절한 열거 타입이나 boolean으로 변환해야 한다 일반화해서 이야기하면 기본 타입이든 참조 타입이든 적절한 값 타입이 있.. 공감수 0 댓글수 0 2022. 4. 21.
item 61 박싱된 기본 타입보다는 기본 타입을 사용하라 ITEM 61 박싱된 기본 타입보다는 기본 타입을 사용하라 자바의 데이터 타입은 크게 두 가지로 나눌 수 있다 기본타입 int, double, boolean 참조타입 String, List 각각의 기본 타입에는 대응하는 참조타입이 하나씩 있으며 이를 박싱된 기본 타입이라고 한다 ex) int, double, boolean 에 대응하는 박싱된 기본타입은 Integer, Double, Boolean이다 오토박싱과 오토언박싱 덕분에 두 타입을 크게 구분하지 않고 사용 가능 하지만 그렇다고 차이가 없는 것은 아니다 둘 상시에는 분명한 차이가 있으니 어떤 타입을 사용할건지는 중요하며 신중하게 선택 해야 한다 기본 타입과 박싱된 기본 타입은 크게 세가지 차이가 있다 기본 타입은 값만 가지고 있지만 박싱된 기본 타입.. 공감수 0 댓글수 0 2022. 4. 21.

문의안내

티스토리
로그인
고객센터

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