개발공부블로그

지역 변수의 유효범위를 최소화하는 가장 강력한 기법은, 처음으로 사용하는 곳에서 선언하는 것이다. 사용하기 전에 선언하면 프로그램의 의도를 알고자 소스 코드를 읽는 사람만 혼란스럽게 할 뿐이다. 또한 거의 모든 지역 변수 선언에는 초기값이 포함되어야 한다. 

 또한 순한문을 잘 쓰면 변수의 유효범위를 최소화할 수 있다. while문보다는 for문을 사용하는 것이 더 좋다. 

또 한가지 기법은 메서드의 크기를 줄이고 특정한 기능에 집중하라는 것이다. 두 가지 서로 다른 기능을 한 메서드에서 처리를 하면 한 가지 기능을 수행하는데 필요한 지역 변수의 유효범위가 다른 기능까지 확장되면서 문제가 생길 가능성이 높다. 

추후에 다시 정리

 마찬가지로 컬렉션을 반환하는 메서드도 빈 컬렉션을 반환해야 할 때마다 동일한 변경 불가능 빈 컬렉션 객체를 반환하도록 구현할 수 있다.

요약

이 메서드는 지정된 자료형의 인자를 0개 이상 받을 수 있다. 동작 원리는 이렇다. 우선, 클라이언트에서 전달한 인자 수에 맞는 배열이 자동 생성되고, 모든 인자가 해당 배열에 대입된다. 그리고 마지막으로 해당 배열이 메서드에 인자로 전달된다. 

요약

 오버로딩된 메서드는 정적(컴파일 시점)으로 선택되지만, 재정의된 메서드는 동적(실행 시점)으로 선택되기 때문이다.  즉 재정의 메서드 가운데 하나를 선택할 때는 객체의 컴파일 시점 자료형은 아무런 영향을 주지 못하며, 오버로딩에서는 반대로 실행시점 자료형이 아무 영향도 주지 못한다.. 실행될 메서드는 컴파일 시에, 인자의 컴파일 시점 자료형만을 근거로 결정된다. 

 이러한 오버로딩의 문제점을 해결하기 위해서는 아래와 같이 작성하는 것이 최선이다. 오버로딩 된 세 classify 메서드를 하나로 합치고, 그 안에서 instanceof 연산자를 사용해 자료형을 검사하는 것이다.

요약

메서드 이름은 신중하게 고르라.  이해하기 쉬우면서도 같은 패키지 안의 다른 이름들과 일관성이 유지되는 이름을 고르는 것이다.  또한 좀 더 널리 합의된 사항에도 부합하는 이름을 고르는 것. 모르겠다면 자바 라이브러리 API이름들이 어떻게 지어졌는지 참고해 보자.

• 여러 메서드로 나누는 것. 각각의 메서드는 여러 인자의 일부만을 취하며, 메서드가 너무 많이 생성되지 않게 주의하도록 한다.
• 도움 클래스를 만들어 인자들을 그룹별로 나누는 것이다. 예를들어 카드의 숫자와 모양 등을 인자로 받는 메서드를 만든다고 했을 때, 각각을 인자로 받는 것보다 카드의 숫자와 모양등을 멤버로 가지고 있는 도움클래스를 인자로 전달하여 사용하는 것이 좋다.
• 빌더패턴을 고쳐서 객체 대신 메서드 호출에 적용하는 것이다. 

인자의 자료형은 클래스보다는 인터페이스가 좋다. 인터페이스 대신에 클래스를 ㅏㅅ용하면 클라이언트는 특정한 구현에 종속되기 때문이다. 

우리가 만드는 클래스의 클라이언트가 불변식을 망가뜨리기 위해 최선을 다할 것이라는 가정하에, 방어적으로 프로그래밍을 해야한다.  그러니 클라이언트가 이상한 짓을 해도 안정적으로 동작하는 클래스를 만들기 위해 노력해야 한다.

 생성자와 접근자를 이렇게 수정하고 나면 Period는 진정한 변경 불가능 클래스가 된다. 

요약

대부분의 메서드와 생성자는 인자로 사용할 수 있는 값을 제한한다. 이런 제한들은 반드시 문서로 남겨야 할 뿐 아니라 메서드 시작 부분에서 검사해야 한다. 오류는 가급적 빨리 탐지해야 한다는 일반 원칙의 특수한 경우이다.

 이런 오류를 생략한다면 어떻게 될까? 

• 첫 째, 처리 도중에 이상한 예외를 내면서 죽어버리는 경우. 
• 둘 째, 실행이 제대로 되는 것 같은데 잘못된 결과가 나오는 것. 
• 셋 째, 정상적으로 반환값을 내기는 하지만 어떤 객체의 상태가 비정상적으로 바뀌는 경우. 

위와 같은 골치아픈 상황을 보게 될 것이다. 그러나 메서드가 실제 계산을 수행하기 전에 그 인자를 반드시 검사해야 한다는 원칙에도 예외는 있다. 그 중 가장 중요한 것은 유효성 검사를 실행하는 오버헤드가 너무 크거나 비현실적이고, 계산 과정에서 유효성 검사가 자연스럽게 이루어지는 경우이다.  

 때로는 계산 과정에서 암묵적으로 유효성 검사가 이루어지기는 하는데, 검사가 실패했을 때 엉뚱한 예외가 던져지는 경우가 있다. 계산 도중에 인자 값이 잘 못되어 발생하는 예외가 메서드 문서에 명시된 예외가 다를 수 있다는 것인데, 이런 경우는 예외 변환을 통해 메서드 문서에 명시된 예외로 변환해야 한다.

 이번 절의 내용을 잘 못 받아 들여 "인자에 제약을 두는 것은 바람직하다" 라고 믿어 버리면 위험하다. 메서드는 가능하다면 일반적으로 적용할 수 있도록 설계해야 한다.  인자로 받는 모든 값에 대한 처리가 잘 되어있다면, 인자에 대한 제약은 적을수록 좋다.

요약