메소드

추상화 수준이 비슷한 메소드 호출로 하나의 메소드를 구성

읽기좋은 메소드의 길이 5~15줄을 넘어가면 안된다고 한다.
전체 구조를 읽을때는 긴메소드가 좋다 하지만 세부사항을 이해하려할때 긴메소드는 방해가 된다.

메소드의 크기를 결정하는 다른 요소는 특화 이다. 적당한 크기의 메소드면 메소드를 하위로 복사하지 않고 손쉽게 오버라이드 가능하다

메소드를 구성할 때는 추측이 아닌 사실에 근거 하라. 일단 동작하는 코드를 만들고 구성 방식을 결정하라.

세세하게 메소드를 나누기 어려울때는 모든 메소드를 인라인 시켜서 커다란 메소드를 만든후 메소드 구현에서 새로 얻은 경험을 바탕으로 다시 메소드를 나누는 방법을 사용

메소드 사용자는 메소드 이름을 통해 메소드 의도를 쉽게 파악 할수 있어야 한다.

구현 전략은 메소드 이름에 가장 자주들어가는 부가정보이다.
프로그래머가 갖고 있는 모든 정보를 당장 전달하는 것이 능사는 아니다.

메소드 이름을 지을 때는 그 메소드를 호출하는 입장에서 생각해보라

기존 인터페이스에 대한 유서점을 사용해서 메소드를 구현한다면 인터페이스에 사용된 것과 같은 이름을 사용하라.

네 가지 수준 - 공용, 패키지, 보호, 전용 의 메소드 가시성 역시 프로그래머의 의도를 전달한다.

메소드 가시성에 있어 상충하는 두가지 주요 요소는 외부 사용자에게 기능을 노출 시켜야 하는 것과 미래 수정에 대한 유연성이다.
좀더 많은 기능을 노출시킬수록 객체에 대한 인터페이스를 수정하기는 어려워진다.

가시성을 선택할때 두가지 비용을 고려해야 한다.

켄트벡의 전략

가급적 가시성을 낮추는 전략
public - 패키지 외부에서도 이메소드가 유용한것이라고 이야기하는것 메소드를 수정할때 본인이 모두 담당하거나, 최소한 사용자들에게 수정 사항을 알려줄 책임이 있다.
package - 패키지 가시성은 해당 메소드가 같은 패키지의 다른 객체에는 유용하지만 패키지 외부의 객체에는 공개하지 않겠다.
protected - 하위 클래스를 사용해서 코드를 재사용할때 유용
private - 외부 객체와 상관 없이 모든 메소드 호출을 제어할 수 있다는 점에서 전용 메소드는 최고의 유연성을 확보해준다.

먼저 가장 제한적인 가시성을 선택한 후 필요에 따라 조금씩 가시성을 높여라

메소드를 final로 선언하는것은 그메소드를 사용하는것은 자유지만 더이상 그메소드를 바꿀수는 없다. 변경하는것이 매우 복잡 할 경우

메소드를 static으로 선언하면 다른 객체에서 해당 클래스의 인스턴스에 접근할 수 없는 경우에도 메소드에 접근할수 있다.
정적 메소드는 어떤 인스턴스의 상태에 의존할 수 없으므로 복잡한 로직을 구현하기에 적합하지 않다.

메소드 객체 패턴은 가끔 사용됨에도 불구하고 사용할 때마다 놀라운 결과를 보여주기 때문에 개인적으로 좋아하는 패턴이다.
파라미터와 임시변수를 클래스의 상의 필드로 만들어서 처리하는 방법이다.

참조