한국도로공사 공고를 추가하면서 BidCandidateCollector라는 인터페이스를 만들었다.
기존에는 나라장터 API를 기준으로 공고를 가져왔다.
근데 수집원이 늘어나면서 공고를 가져오는 방식은 달라도 이후 검토 로직은 같이 사용해야 했다.
수집원마다 낙찰방법이나 참가조건을 판단하는 코드를 따로 만들 필요는 없으니까.
인터페이스
클래스가 구현해야 하는 기능의 공통 형태를 정해두는 것.
Biz Assist에서 작성한 코드.
public interface BidCandidateCollector {
List<BidQualificationDto> collect(
LocalDate startDate,
LocalDate endDate
);
}collect()는 시작일과 종료일을 받아 해당 기간의 공고를 BidQualificationDto 목록으로 반환한다.
어느 사이트에서 어떻게 공고를 가져올지는 인터페이스에 작성하지 않았다.
그 부분은 구현 클래스에서 처리한다.
구현 클래스에서는?
한국도로공사 수집기인 KoreaExpresswayBidCollector가 BidCandidateCollector를 구현한다.
public class KoreaExpresswayBidCollector
implements BidCandidateCollector {
@Override
public List<BidQualificationDto> collect(
LocalDate startDate,
LocalDate endDate
) {
// 한국도로공사 공고 수집 및 DTO 변환
}
}위 코드는 구조를 보기 위한 축약 예시다.
다른 수집원이 추가되면 같은 인터페이스를 구현하되 각 사이트에 맞는 수집 코드를 작성하면 된다.
실제 Biz Assist에서는
for (BidCandidateCollector collector
: additionalBidCandidateCollectors) {
for (BidQualificationDto candidate
: collector.collect(startDate, endDate)) {
applyExternalCheckResult(candidate);
applyAwardMethodClassification(candidate);
applyReviewResult(candidate, normalizedCodes);
addUniqueCandidate(uniqueCandidates, candidate);
}
}여기서는 수집기가 한국도로공사인지 다른 사이트인지 구분하지 않는다.
collect()를 호출한 뒤 공통 검토 로직을 실행한다.
참고로 나라장터는 기존 API 조회 흐름을 사용한다. BidCandidateCollector는 나라장터 외의 추가 수집원을 연결하려고 만든 인터페이스다.
인터페이스와 추상 클래스
| 구분 | 인터페이스 | 추상 클래스 |
|---|---|---|
| 선언 | interface | abstract class |
| 사용 | implements | extends |
| 여러 개 적용 | 여러 인터페이스 구현 가능 | 클래스 상속은 하나만 가능 |
| 생성자 | 없음 | 있음 |
| 공통 구현 | default 메서드 등 | 일반 메서드 |
인터페이스도 default 메서드로 구현 코드를 작성할 수 있다.
다만 이번에는 수집원마다 공고를 가져오는 방식이 달랐고 공통 구현을 공유하기보다 같은 collect() 메서드를 제공하는 게 필요했다.
그래서 BidCandidateCollector를 인터페이스로 만들었다.
