Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Chap10.Making Method Calls Simpler

356 views

Published on

Refactoring.

Chapter10.
Making Method Calls Simpler

Published in: Education
  • Be the first to comment

  • Be the first to like this

Chap10.Making Method Calls Simpler

  1. 1. Chapter10.Making Method Calls SimplerMaking Method Calls Simpler 2012.08.21 박태민
  2. 2. Rename MethodAdd Parameter Introduce Parameter ObjectRemove Parameter Remove Setting MethodSeparate Query from Hide MethodModifier Replace Constructor withParameterize Method Factory MethodReplace Parameter with Encapsulate DowncastExplicit Methods Replace Error Code withPreserve Whole Object ExceptionReplace Parameter with Replace Exception with TestMethod
  3. 3. Replace Error Code withRename Method Exception vs Replace Exception withAdd Parameter Testvs Remove Parameter Remove Setting MethodParameterize Method & Hide Methodvs Replace Parameter withExplicit Methods Replace Constructor with Factory MethodPreserve Whole Objectvs Introduce Parameter Object Separate Query from ModifierReplace Parameter withMethod Encapsulate Downcast
  4. 4. Rename Method 메소드의 이름이 그 목적을 드러내지 못하고 있다면 메소 드의 이름을 바꿔라 !! 메소드의 이름을 바로 바꾸는 것이 아니라 새로운 메소드 를 만들고 참조를 변경하라 .
  5. 5. Add Parameter 어떤 메소드가 그 메소드를 호출하는 부분에서 더 많은 정보를 필요로 한다면 , 이 정보를 넘길 수 있는 객체에 대한 파리머터를 추가하라 !! 가능하면 다른 대안을 찾고 , 이 리펙토링은 하지 않는다 . 긴 파라미터 리스트는 기억하기 어렵고 종종 데이터 덩어리를 필요로 하기 때 문에 안좋다 . => Introduce Parameter Object 파라미터에 어떤 값이라도 넘길 수 있지만 , 일반적으로 객체 파라미터에는 null 을 넘기고 , 기본형 파라미터에는 명확히 이상한 값을 넘긴다 .
  6. 6. Remove Parameter 파라미터가 메소드 몸체에서 더 이상 사용되지 않는다면 , 그 파라미터를 제거하라 . 파라미터를 제거하는 것은 쉬운 리펙토링이다 . 불필요한 파라미터를 제거하지 않음으로 인해 , 그 메소 드를 사용하는 모든 사람들이 일이 더 많이 하게 만든다 .
  7. 7. Parameterize Methodvs Replace Parameter with Explicit Methodsvs Replace Parameter with Explicit Methods 몇몇 메소드가 메소드 몸체에 다른 값을 포 함하고 있는 것을 제외하고는 비슷한 일을 하고 있다면 , 다른 값을 파라미터로 넘겨 받 는 하나의 메소드를 만들어라 . ==> 중복된 코드가 없어지고 유연성이 좋아 진다 . 파라미터의 값에 따라서 다른 코드를 실행하 는 메소드가 있다면 , 각각의 파라미터 값에 대한 별도의 메소드를 만들어라 . ==> 조건에 따른 행동을 피할 뿐만 아니라 컴파일 할 때 확인을 할 수 있다 . 또한 인터 페이스가 좀 더 명확해진다 .
  8. 8. Preserve Whole Objectvs Introduce Parameter Objectvs Introduce Parameter Object 어떤 객체에서 여러 개의 값을 얻은 다음 메소드를 호출하면서 파라미터로 넘 기고 있다면 , 대신 그 객체 를 파라미터로 넘겨라 !! 정의된 객체가 없을 때는 Introduce Parameter Object 와 같이 새로운 객체를 정의한다 .
  9. 9. Remove Setting Method & Hide Method & Hide Method 어떤 필드가 객체 생성시에 값이 정해지고 그 이후에는 변경되지 않아야 한다면 , 그 필드값을 설정하는 모든 메 소드를 제거하라 !! 어떤 필드 값이 바뀌는 것을 원하지 않는다면 , 그 필드에 메소드가 다른 클래스에서 사용되지 않는다면 , 그 메 대한 set method 를 제공하 소드를 private 으로 만들어라 . 지 마라 . ( 그리고 그 필드를 final 로 만들어라 .)
  10. 10. Replace Constructor with Factory Method 객체를 생서알 때 단순히 생성하는 것 이외 에 다른 작업도 하고 있다면 , 생성자를 팩 토리 메소드로 대체하라 . ==> 생성자를 호출하는 부분을 모두 팩토리 메소드를 사용하도록 바꾸고 , 생성자를 private 으로 만든다 . 문자열을 이용한 서브클래스 객체 생성 ==> Class.forName() 사용 ==> 새로운 subclass 를 추가하더라도 create 메소드를 업데이트 할 필욕 ㅏ없다 는 점에서 좋다 . ==> 그러나 , 컴파일 할 때 오류체크할 수 없다 . 명시적인 메소드로 서브클래스 객체 생성 ==> 변하지 않는 단지 몇개의 서브클래스 만 가지고 있다면 이 방법이 유용하다 .
  11. 11. Encapsulate Downcast 메소드가 그 호출부에서 다운캐스트 (downcast) 될 필요 가 있는 객체를 리턴하고 있다면 , 다운캐스트 하는 것을 메소드 안으로 옮겨라 . 다운캐스팅은 필요악일지도 모른다 . ==> 가능하면 다운 캐스팅을 적게 사용해야 한다 .
  12. 12. Separate Query from Modifier 값을 리턴할 뿐만 아니라 객체의 상태도 변경하는 메소드 를 가지고 있는 경우 , 두 개의 메소드를 만들어서 하나는 값을 리턴하는 역할을 하고 , 하나는 객체의 상태를 변경 하는 역할을 하게 하라 !! 값을 리턴한느 동시에 부작용도 가지고 있는 메소드를 발 견한다면 , 질의하는 부분과 변경하는 부분을 분리해야 한다 .
  13. 13. Replace Error Code with Exception vs Replace Exception with Test vs Replace Exception with Test 메소드가 에러를 나타내는 특별한 코드를 가지고 있다면 , 대신 예외를 던져라 !! 호출부에서 먼저 검사할 수 있는 조건에 대해 예외를 던지고 있다면 , 호출부가 먼저 검사하도 록 바꿔라 !! ==> 예외는 예외적인 동작에 대해서 사용되어야 한다 . 예외가 조건 테스트를 대신하는 역할을 하면 안된다 .
  14. 14. 정리 .. 적당한 이름이 아니면 , 이름을 변경 !! 추가적인 파라미터가 필요하면 파라미터 추가 !! 파라미터가 길어질 때는 객체를 넘기는 것을 고 려 !! 불필요한 파라미터는 바로 제거 !! 어떤 필드가 생성후 변경이 없다면 셋터제거 !! 생성자 private!! 메소드도 다른 클래스에서 생성되지 않으면 private 으로 감춤 !! 적절한 예외 사용 !! 상황에 따라 호출하는 곳에 서 검사하도록 수정 !!
  15. 15. End.

×