Chapter10. Making Method Calls Simpler

2012.08.21박태민

Rename Method

Add Parameter

Remove Parameter

Separate Query from Modifier

Parameterize Method

Replace Parameter with Explicit Methods

Preserve Whole Object

Replace Parameter with Method

Introduce Parameter Object

Remove Setting Method

Hide Method

Replace Constructor with Factory Method

Encapsulate Downcast

Replace Error Code with Exception

Replace Exception with Test

Rename Method

Add Parametervs Remove Parameter

Parameterize Method vs Replace Parameter with Explicit Methods

Preserve Whole Objectvs Introduce Parameter Object

Replace Parameter with Method

Replace Error Code with Exceptionvs Replace Exception with Test

Remove Setting Method& Hide Method

Replace Constructor with Factory Method

Separate Query from Modifier

Encapsulate Downcast

Rename Method

메소드의 이름이 그 목적을 드러내지 못하고 있다면 메소드의 이름을 바꿔라 !!

메소드의 이름을 바로 바꾸는 것이 아니라 새로운 메소드를 만들고 참조를 변경하라 .

Add Parameter

어떤 메소드가 그 메소드를 호출하는 부분에서 더 많은 정보를 필요로 한다면 , 이 정보를 넘길 수 있는 객체에 대한 파리머터를 추가하라 !!

가능하면 다른 대안을 찾고 , 이 리펙토링은 하지 않는다 .

긴 파라미터 리스트는 기억하기 어렵고 종종 데이터 덩어리를 필요로 하기 때문에 안좋다 .=> Introduce Parameter Object

파라미터에 어떤 값이라도 넘길 수 있지만 , 일반적으로 객체 파라미터에는 null 을 넘기고 , 기본형 파라미터에는 명확히 이상한 값을 넘긴다 .

Remove Parameter

파라미터가 메소드 몸체에서 더 이상 사용되지 않는다면 , 그 파라미터를 제거하라 .

파라미터를 제거하는 것은 쉬운 리펙토링이다 .

불필요한 파라미터를 제거하지 않음으로 인해 , 그 메소드를 사용하는 모든 사람들이 일이 더 많이 하게 만든다 .

Parameterize Methodvs Replace Parameter with Explicit Methods

몇몇 메소드가 메소드 몸체에 다른 값을 포함하고 있는 것을 제외하고는 비슷한 일을 하고 있다면 , 다른 값을 파라미터로 넘겨 받는 하나의 메소드를 만들어라 .==> 중복된 코드가 없어지고 유연성이 좋아진다 .

파라미터의 값에 따라서 다른 코드를 실행하는 메소드가 있다면 , 각각의 파라미터 값에 대한 별도의 메소드를 만들어라 .==> 조건에 따른 행동을 피할 뿐만 아니라 컴파일 할 때 확인을 할 수 있다 . 또한 인터페이스가 좀 더 명확해진다 .

Preserve Whole Objectvs Introduce Parameter Object

어떤 객체에서 여러 개의 값을 얻은 다음 메소드를 호출하면서 파라미터로 넘기고 있다면 , 대신 그 객체를 파라미터로 넘겨라 !!

정의된 객체가 없을 때는 Introduce Parameter Object 와 같이 새로운 객체를 정의한다 .

Remove Setting Method & Hide Method

어떤 필드가 객체 생성시에 값이 정해지고 그 이후에는 변경되지 않아야 한다면 , 그 필드값을 설정하는 모든 메소드를 제거하라 !!

어떤 필드 값이 바뀌는 것을 원하지 않는다면 , 그 필드에 대한 set method 를 제공하지 마라 . ( 그리고 그 필드를 final 로 만들어라 .)

메소드가 다른 클래스에서 사용되지 않는다면 , 그 메소드를 private 으로 만들어라 .

Replace Constructor with Factory Method

객체를 생서알 때 단순히 생성하는 것 이외에 다른 작업도 하고 있다면 , 생성자를 팩토리 메소드로 대체하라 .==> 생성자를 호출하는 부분을 모두 팩토리 메소드를 사용하도록 바꾸고 , 생성자를 private 으로 만든다 .

문자열을 이용한 서브클래스 객체 생성==> Class.forName() 사용==> 새로운 subclass 를 추가하더라도 create 메소드를 업데이트 할 필욕 ㅏ없다는 점에서 좋다 .==> 그러나 , 컴파일 할 때 오류체크할 수 없다 .

명시적인 메소드로 서브클래스 객체 생성==> 변하지 않는 단지 몇개의 서브클래스만 가지고 있다면 이 방법이 유용하다 .

Encapsulate Downcast

메소드가 그 호출부에서 다운캐스트 (downcast) 될 필요가 있는 객체를 리턴하고 있다면 , 다운캐스트 하는 것을 메소드 안으로 옮겨라 .

다운캐스팅은 필요악일지도 모른다 .==> 가능하면 다운 캐스팅을 적게 사용해야 한다 .

Separate Query from Modifier

값을 리턴할 뿐만 아니라 객체의 상태도 변경하는 메소드를 가지고 있는 경우 , 두 개의 메소드를 만들어서 하나는 값을 리턴하는 역할을 하고 , 하나는 객체의 상태를 변경하는 역할을 하게 하라 !!

값을 리턴한느 동시에 부작용도 가지고 있는 메소드를 발견한다면 , 질의하는 부분과 변경하는 부분을 분리해야 한다 .

Replace Error Code with Exception vs Replace Exception with Test

메소드가 에러를 나타내는 특별한 코드를 가지고 있다면 , 대신 예외를 던져라 !!

호출부에서 먼저 검사할 수 있는 조건에 대해 예외를 던지고 있다면 , 호출부가 먼저 검사하도록 바꿔라 !!==> 예외는 예외적인 동작에 대해서 사용되어야 한다 . 예외가 조건 테스트를 대신하는 역할을 하면 안된다 .

정리 ..

적당한 이름이 아니면 , 이름을 변경 !!

추가적인 파라미터가 필요하면 파라미터 추가 !!

파라미터가 길어질 때는 객체를 넘기는 것을 고려 !!

불필요한 파라미터는 바로 제거 !!

어떤 필드가 생성후 변경이 없다면 셋터제거 !! 생성자 private!!

메소드도 다른 클래스에서 생성되지 않으면 private으로 감춤 !!

적절한 예외 사용 !! 상황에 따라 호출하는 곳에서 검사하도록 수정 !!

End.