[Java] 인터페이스를 통해 if문의 향연을 고쳐보았다.

상황

물건의 최소 시세값이 '5억', 최대 시세값이 '10억' 이라고 세팅 되었다고 할 때,

- 사용자의 물건이 7억이면?  필터링을 통과한다. 👉 5억과 10억 사이기 때문이다.

- 사용자의 물건이 3억이면? 필터링을 통과하지 못한다. 👉5억과 10억 사이가 아니기 때문이다. 

 

 

 

이에 대한 필터링 코드를 작성했고, 이를 리팩토링 하는 과정을 정리해보고자 한다.

 

결론 비교 화면 

 

---

 

리팩토링 전 코드

 

 

딱 봐도 if 문의 향연 그 잡채다.

 

최소값과 최대값이 항상 둘 다 세팅된다는 보장이 없기에

(1) 최소값 / 최대값이 둘 다 세팅되었을 때

(2) 최대값만 세팅되었을 때

(3) 최소값만 세팅되었을 때 

를 나누어 조건을 분리하는 그런 코드이다.

 

필터링을 수행하는데 크게 이상은 없지만, if 문이 너무 많아 보기 좋아보이지 않는다.

그냥 나열식으로 작성했다는 느낌이 강하다.

 

 

---

리팩토링 후 코드

 

 

 

 

A코드와 비교하여 B 코드는 무엇이 달라졌을까?

 

1. 비교 방법의 변경

A 코드에서는 userMarketValue를 minMarketValue와 maxMarketValue와 각각 비교하여 조건을 확인한다.

이를 위해 비교 연산자와 조건문을 명시적으로 사용해야 한다.

B 코드에서는 validate 메서드 내에서 람다 표현식을 사용하여 비교 조건을 간결하게 정의한다.

람다 표현식을 사용하면 비교 조건이 더 직관적으로 표현되며,

코드 블록 내에서 필요한 조건을 명확하게 정의할 수 있습니다.

 

2. 람다 표현식 활용

B 코드에서 람다 표현식은 Compare 함수형 인터페이스를 구현하여 사용된다.

이 인터페이스는 단일 메서드(boolean compare(BigDecimal userValue, BigDecimal targetValue))를 가지며,

이 메서드는 비교 조건을 나타낸다.

람다 표현식을 사용하면 코드가 가독성이 높아지며,

필터링 조건을 변경하거나 수정할 때 코드를 더 쉽게 유지하고 확장할 수 있다.

 

3. 코드의 모듈화와 재사용성

B 코드에서는 비교 동작을 Compare 인터페이스를 통해 모듈화한다.

이 인터페이스는 코드의 일부분으로 추상화되며, 다양한 비교 조건을 정의할 수 있다.

이로써 코드의 재사용성이 향상되고, 동일한 비교 로직을 여러 곳에서 사용할 수 있다.