본문 바로가기
[Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 [Effective Java] 독자적인 직렬화 형태의 사용을 고려하자 - 클래스를 설계할 때 클래스가 Serializable 을 구현하면서 기본 직렬화 형태를 사용한다면, 나중에 함부로 버릴 수 없고, 그 직렬화 형태를 계속 유지해야 할 가능성이 높다. - 적합 여부를 우선적으로 고려해보고 기본 직렬화 형태를 수용하자. 기본 직렬화 형태는 유연성, 성능, 정확성의 관점에서 타당하다는 결정이 섰을 때 사용해야 한다. 일반적으로 말하면, 우리가 독자적인 직렬화 형태를 설계한다고 할 때 하게될 인코딩과 대부분 같은 경우에만 기본 직렬화 형태를 사용해야 한다. - 이상적인 객체 직렬화 형태는 그 객체가 표현하는 논리적 데이터만 포함한 것이다. - 기본 직렬화 형태는 객체의 물리적 표현이 논리적인 내용과 동일할 .. 2017. 3. 23.
[Effective Java] 스레드 안전을 문서화 하자. [Effective Java] 스레드 안전을 문서화 하자. - 클래스 행동을 문서화하지 않으면, 프로그래머는 가정에 의존해서 그 클래스를 사용해야 한다. 만일 그런 가정들이 잘못되면, 그로 인한 프로그램은 불충분한 동기화나 과도한 동기화를 하게 될 것이다. 어떤 경우든, 심각한 에러가 유발될 수 있다. - 메소드 선언부의 synchronized 변경자는 메소드의 상세 구현 부분이지 외부로 제공되는 API 가 아니다. 즉 Javadoc 에 synchronized 가 공개되지 않는다. synchronized 변경자가 있다는 것이 스레드 안전을 문서화하기에 충분한 것은 아니다. 동시적 사용을 안전하게 하려면, 해당 클래스가 어떤 수준의 스레드 안전을 지원하는지 명확하게 문서화해야 한다. - 다음은 스레드 안전.. 2017. 3. 14.
[Effective Java] 지나친 동기화는 피하자 [Effective Java] 지나친 동기화는 피하자 - 지나친 동기화는 성능을 저하시키고 교착상태(dead lock)을 유발시키며, 심지어 예기치 않은 행동을 초래할 수 있다. - 동기화된 메소드나 블록 안에서 절대로 클라이언트에게 제어권을 넘기면 안 된다. 즉, 동기화된 영역 내부에서는 오버라이딩된 메소드를 호출하지 않아야 하며, 함수 객체의 형태로 클라이언트가 제공하는 메소드도 호출하지 말아야 한다. 동기화된 영역을 갖는 클래스의 관점에서 그런 메소드들은 매우 이질적인 녀석들이다. 그 메소드가 무슨 일을 하는지 알지 못하며, 이질적인 일을 하는 것을 제어하지도 못한다. 외계인 메소드가 하는 일에 따라 다르겠지만, 동기화된 영역에서 그 메소드를 호출하면 예외나 dead lock 또는 데이터 손상까지 .. 2017. 3. 9.
[Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. [Effecitve Java] 리플렉션보다는 인터페이스를 사용하자. - 리플렉션은 여러모로 강력한 기능을 제공한다. 하지만 이런 강력함은 다음의 대가들을 수반한다. 컴파일 시점에 가능한 타입 확인의 장점이 없어진다. 재귀적인 접근을 필요로 하는 코드는 알아 보기 어렵고 길다. 처리 성능이 늦다. - 사실 리플렉션은 컴포넌트 기반의 어플리케이션 개발 도구용으로 설계되었다. 따라서 일반적으로 런타임에서는 리플렉션을 이용해서 재귀적으로 사용하면 안된다. - 리플렉션이 필요한 복잡한 애플리케이션은 다음과 같다. 클래스 브라우저 객체 조사기 코드 분석 도구 RPC - 리플렉션을 지극히 제한된 형태로만 사용하여 비용이 거의 수반되지 않도록 한다면 리플렉션의 많은 장점을 얻을 수 있다. 예를 들어 컴파일 시점에는 쓸.. 2017. 2. 13.
[Effective Java] 객체 참조는 그 객체의 인터페이스 타입으로 하자 [Effective Java] 객체 참조는 그 객체의 인터페이스 타입으로 하자 - 객체를 참조할 때는 클래스보다는 인터페이스를 사용해야 한다. 만일 적합한 인터페이스 타입이 있다면, 매개 변수, 반환 값, 변수, 필드 모두 다 인터페이스 타입을 사용해서 선언해야 한다. 유일하게 객체의 클래스를 참조할 필요가 있는 경우는 생성자에서 객체를 생성할 때이다. - 인터페이스를 객체의 타입으로 사용하는 습관을 들이면, 프로그램이 훨씬 더 유연해진다. - 인터페이스의 구현체(클래스)를 변경하고자 하는 이유는, 새로 변경한 구현체가 더 좋은 성능을 내는 경우가 많다. - 만일 적합한 인터페이스가 없다면, 객체를 참조하는 타입을 인터페이스 대신 클래스로 하는 수밖에 없다. 적합한 인터페이스가 없는 경우는 보통 fina.. 2017. 2. 9.
[Effective Java] 외부에 제공하는 모든 API 요소에 대해 문서화 주석을 넣자. [Effective Java] 외부에 제공하는 모든 API 요소에 대해 문서화 주석을 넣자. - 사용 가능한 API 라면 반드시 문서화해야 한다. 만일 문서화 주석 규칙에 친숙하지 않다면 배워야 한다. - API 를 문서화하려면, 외부에 제공하는 모든 클래스, 인터페이스, 생성자, 메소드, 필드의 선언부 앞에 문서화 주석을 넣어야 한다. 만일 어떤 클래스가 직렬화될 수 있다면 직렬화 형태도 문서화해야 한다. - 문서화 주석이 빠진 API 를 사용하는 것은 실망스럽고 에러가 생길 가능성이 많다. 유지보수 하기 쉬운 코드를 작성하려면 외부에 공개되지 않는 대부분의 클래스, 인터페이스, 생성자, 메소드, 필드에 대해서도 문서화 주석을 작성해야 한다. - 메소드의 문서화 주석에서는 메소드와 클라이언트 사이의 계.. 2017. 1. 23.
[Effective Java] 메소드 시그니처를 신중하게 설계하자. [Effective Java] 메소드 시그니처를 신중하게 설계하자. - 메소드 이름을 신중하게 짓자. 이름은 항상 표준 작명 규칙을 따라야 한다. 이름에는 일관성이 있어야 한다. 폭넓게 공감 가는 이름을 선택해야 한다. - 편리한 메소드를 만드는데 너무 열중하지 말자. 모든 메소드는 자신의 역할을 해야 한다. 메소드가 너무 많으면, 클래스를 배우고 사용하고 문서화하고 테스트하고 유지하기가 어렵다. 클래스나 인터페이스가 지원하는 각 동작에 대해서 충분한 기능을 수행하는 메소드를 제공하자. - 너무 많은 매개 변수를 피하자. 매개 변수는 네 개 이하를 목표로 하자. 매개 변수가 네 개를 넘으면 시종일관 문서를 참조하지 않고는 그 메소드 API 를 사용할 수 없다. 같은 타입의 매개 변수가 길게 나오면 특히 .. 2017. 1. 12.
[Effective Java] 필요하면 방어 복사본을 만들자. [Effective Java] 필요하면 방어 복사본을 만들자. - 자바는 꽤나 안전한 언어이지만, 우리 클래스의 클라이언트가 불변 규칙을 파괴하기 위해 최선을 다할 거라는 가정하에 방어적으로 프로그램을 작성해야 한다. - 가변 객체인 매개 변수는 각각의 방어복사본(defensive copy)을 만들어서 생성자에 전달해야 한다. 그렇지 않으면 예상치 못한 여러 상황이 발생할 수 있다. - 방어복사본은 매개 변수의 유효성 검사에 앞서 만들어야 하며, 유효성 검사는 원본이 아닌 복사본을 대상으로 해야 한다!! ( TOCTOU 공격 ( 검사시간/사용시간) 이슈 ) - clone 은 위험한 복사방법이므로 가급적이면 다른 방법으로 복제하자. final 이 아닌 Class 는 sub class 가 clone 을 상속.. 2017. 1. 10.
[Effective Java] 타입 정의는 표시 인터페이스를 사용하자. [Effective Java] 타입 정의는 표시 인터페이스를 사용하자. - 표시 인터페이스(marker interface)는 메소드 선언은 전혀 없으면서 클래스가 그 인터페이스를 구현하는지만 나타내는(표시하는) 인터페이스이다. - annotation 이 이를 대체할 수도 있겠지만, marker interface 는 annotation 에 비해 두 가지 장점이 있다. 1. marker interface 는 표시된 클래스의 인스턴스에 의해 구현되는 타입을 정의한다. 2. 더 정확한 목표를 가질 수 있다. ( annotation 은 class 한정이 아니다. ) - annotation 도 장점이 있다. 1. 주요 장점은 이미 발표되어 사용 중이라도 기본적으로 하나 이상의 주석 타입 요소들을 추가함으로써 더 많.. 2017. 1. 5.
반응형

티스토리툴바