DevOps : 리팩토링 기법 (2)

리팩토링

 

클래스 추출

처음에 해당 클래스가 담당할 책임이 정확히 무엇인지 관련 기능을 포함하는 클래스를 생각해야 합니다. 이는 단일 책임 원칙을 준수하는 데 중요하고, 단일 책임 클래스는 안정적이고 변경에 좀 더 유연합니다. 물론 과도하게 리팩토링하는 것은 아닌지 항상 주의해야 합니다. 기존 코드를 복사해 쓰는 건 훨씬 빠르게 느껴지지만 이렇게 복사한 코드는 중복이기 때문에 곧 문제가 되고, 모든 소프트웨어의 가장 심각한 문제로 발전하게 됩니다.

 

 

상위 클래스로 추출

두 개 이상의 클래스들 중에 공통적인 소스가 있을 경우 공통적으로 사용하게 추출할 수 있습니다.

MinorMember와 SeniorMember 클래스에서 공통적으로 멤버 ID로 DB 쿠폰을 조회 후 그 중 현재 기준으로 사용가능한 쿠폰을 설정 후 개별 클래스에 맞는 별도 로직을 처리한다고 가정합니다. 네모 부분을 유틸리티 메서드로 만들 수도 있지만 Java 메서드는 반드시 클래스에 있어야 하므로 추출한 유틸리티 메서드는 클래스 내부에 각각 존재하게 되어 문제가 될 가능성이 높으므로 별도의 상위 클래스로 추출하는 것이 좋습니다.

SeniorMember 소스입니다. 사용가능한 쿠폰을 조회하는 기능을 하는 메서드를 공통적으로 사용하기 때문에 추출하여 개별 클래스에서 사용되는 상위 클래스를 만듭니다. 사실 상속은 강력하지만 객체지향의 캡슐화를 깨는 문제가 될 수 있고, 상위 클래스와 하위 클래스 간 is-a 관계일 때만 사용해야 합니다.

상-하위 클래스 간 패키지가 다르거나 상위 클래스가 확장을 고려해 설계되지 않았다면 향후 문제가 될 수 있습니다. 그럴 경우 상속보다는 composition과 위임 등의 기법을 고려해야 합니다.

MinorMember와 SeniorMember 클래스는 상위 CommonMember 클래스의 하위 클래스로 변경하면 됩니다. showAvailableCoupon 메서드를 override해서 상위 클래스의 메서드를 호출 후 개별 로직을 처리합니다.

 

 

인터페이스 작게 유지

인터페이스를 작게 유지하려면 4개까지 해야 합니다. 인터페이스의 적절한 크기는 프로젝트 상황에 따라 달라질 수 있습니다. 하지만 크기가 클 경우 Code Smell 여부를 판단할 필요가 있습니다.

메서드는 이메일 메시지를 만들어 전송하는 역할을 하는데, 9개의 파라미터를 받습니다. 파라미터 목록만으로 메서드의 동작을 짐작하기 어렵고, 메서드가 하는 작업도 많습니다. 이메일 주소를 만드는 것도 전송 작업과 관련이 없고, 메시지 내용을 구성하는 파라미터 5개도 헷갈릴 수 있습니다.

리팩토링을 하면 buildAndSendMail 메서드는 메일을 만들 때 Mail 클래스를 호출 후 전송을 하게 됩니다. Mail 클래스는 다시 메일 주소를 만드는 MailAddress 클래스와 메일 내용을 만드는 MailBody 클래스를 호출합니다. 관심사의 분리를 통해 각각의 책임을 가진 클래스들로 구성할 수 있습니다.