본문 바로가기
[Effective Java] 지나친 동기화는 피하자 [Effective Java] 지나친 동기화는 피하자 - 지나친 동기화는 성능을 저하시키고 교착상태(dead lock)을 유발시키며, 심지어 예기치 않은 행동을 초래할 수 있다. - 동기화된 메소드나 블록 안에서 절대로 클라이언트에게 제어권을 넘기면 안 된다. 즉, 동기화된 영역 내부에서는 오버라이딩된 메소드를 호출하지 않아야 하며, 함수 객체의 형태로 클라이언트가 제공하는 메소드도 호출하지 말아야 한다. 동기화된 영역을 갖는 클래스의 관점에서 그런 메소드들은 매우 이질적인 녀석들이다. 그 메소드가 무슨 일을 하는지 알지 못하며, 이질적인 일을 하는 것을 제어하지도 못한다. 외계인 메소드가 하는 일에 따라 다르겠지만, 동기화된 영역에서 그 메소드를 호출하면 예외나 dead lock 또는 데이터 손상까지 .. 2017. 3. 9.
[Effective Java] 메소드가 던지는 모든 예외를 문서화하자. [Effective Java] 메소드가 던지는 모든 예외를 문서화하자. - Javadoc 의 @throws 태그를 사용해서 항상 checked 예외는 별도로 선언하고, 각 예외가 발생하는 상황을 정확하게 문서화하자. 메소드가 던지는 예외가 많다고 해서 메소드 명세에 각 예외를 정확하게 선언하지 않고, 그 예외 클래스의 대표적인 슈퍼 클래스만 함축해서 나타내면 안 된다. - unchecked 예외의 문서 내역은 메소드가 성공적으로 실행되기 위한 사전조건(precondition)을 효과적으로 나타낸다. - 인터페이스에 정의된 메소드의 경우 자신이 던질 수 있는 unchecked 예외를 문서화하는 것이 "특히" 중요하다. 그 인터페이스의 보편적 계약 중 일부분이 되며, 인터페이스를 구현하는 여러 구현체들 간의.. 2017. 2. 28.
[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] 매개 변수가 유효한지 검사하기. - 대부분의 메소드와 생성자는 자신들의 매개 변수로 전달될 수 있는 값에 제한을 둔다. 그런 모든 제약은 명확하게 문서화해야 하며, 메소드 몸체 코드의 맨 앞에서 검사하도록 해야 한다. 이것은 에러가 발생한 후 가능한 빨리 검출해야 한다는 일반적 원칙의 특별한 경우이다. 만일 사전 검사에 실패하면 에러의 검출이 불확실하게 되고, 에러가 생긴 소스 코드를 찾기가 더욱 어려워진다. - public 메소드의 경우는 javadoc 의 @throws 태그를 사용해서 매개 변수 값의 제약을 위반했을 때 발생되는 예외를 문서화한다. 일반적으로 IllegalArgumentException, IndexOutOfBoundsException, NullPointe.. 2017. 1. 9.
[Effective Java] 상속을 위한 설계와 문서화를 하자. 그렇지 않다면 상속의 사용을 금지시킨다. 상속을 위한 설계와 문서화를 하자. 그렇지 않다면 상속의 사용을 금지시킨다. - 메소드 오버라이딩으로 인한 파급 효과를 분명하게 문서화해야 한다. 같은 클래스의 다른 메소드들이 호출하는지에 대해 반드시 문서화해야 한다. ( self-use ) - 각각의 public 이나 protected 메소드 및 생성자가 어떤 오버라이드 가능한 메소드를 호출하는지, 어떤 순서로 하는지, 호출한 경로가 다음 처리에 어떤 영향을 주는지에 대해서도 반드시 문서화해야 한다. 오버라이드 가능하다는 것은 final 이 아니면서 public 이나 protected 인 경우를 의미한다. - 관례적으로 오버라이드 가능한 메소드를 호출하는 메소드에는 문서화 주석의 제일 끝에 그런 호출에 대한 설명을 추가한다. 그리고 설명의 시작은 "이.. 2016. 11. 1.
[Effective Java] 가급적 상속(inheritance) 보다는 컴포지션(composition)을 사용하자. 가급적 상속(inheritance) 보다는 컴포지션(composition)을 사용하자. - 상속은 코드를 재사용하는 강력한 방법이다. 그러나 일을 하는데 가장 좋은 도구는 아니다. 잘못 사용하면 부실한 소프트웨어를 초래한다. - 동일 프로그래머가 서브 클래스와 수퍼 클래스의 구현을 관장하는 같은 패키지 내에서 상속을 사용하는 것은 안전하다 상속을 위해 특별히 설계되고 문서화된 클래스를 확장(extends) 하기 위해 상속을 사용하는 것도 안전하다. 그러나 다른 패키지에 걸쳐 일반적인 실체 클래스로부터 상속을 받는 것은 위험하다. - 상속은 캡슐화(encapsulation) 을 위배한다. 올바른 동작을 위해 서브 클래스는 자신의 수퍼 클래스가 구현하는 상세 내역에 의존한다. 수퍼 클래스의 구현 내역은 소프.. 2016. 10. 27.
[Effective Java] toString 메소드는 항상 오버라이드 하자. [Effective Java] toString 메소드는 항상 오버라이드 하자. - 일반적인 toString() 메소드는 "ClassName@HashCode" 와 같은 형식으로 표시된다. - toString 의 보편적 계약은 간결해야 하지만 사람이 읽기 쉬운 형태의 정보 표현이어야 한다 - 가능하다면 toString 메소드에서는 객체의 모든 중요한 정보를 반환해야 한다. - toString 에서 출력하는 문자열이 한 눈에 무엇인지 파악하기 어렵다면, 문서화를 정확히 해야 한다. className, default, Effective JAVA, hashcode, human readable, override, toString, [Effective Java] toString 메소드는 항상 오버라이드 하자., 간결.. 2016. 10. 7.
반응형