컴파일에서 문제를 잡아내기, 다만 완벽하지는 않다.
- 아래의 코드가 있다고 하자.
String defaultHelpMsg = telegramCommandProperties.getHelp().getDefaultHelpMsg();
메서드가 존재하지 않으면 컴파일 오류가 발생한다. 그러므로 런타임 과정에서 에러가 발생할 수 있는 @Value 보다 추천된다.
@Log4j2
@SpringBootTest(properties = "telegramApi.active=false")
class TelegramCommandPropertiesTest {
@Autowired
TelegramCommandProperties telegramCommandProperties;
@Test
void test1(){
String defaultHelpMsg = telegramCommandProperties.getHelp().getDefaultHelpMsg();
System.out.println("defaultHelpMsg = \n" + defaultHelpMsg);
}
}
- 하지만 완벽하지 않다. 프로퍼티스에 help.default-help-msg 를 정의하지 않으면 어떨까?
- 해당 값은 null 로 나온다.
- @Value 보단 분명 안전하지만 그러나 존재하지 않는 메시지에 대해서까지 완전하게 통제하진 못한다.
메시지를 클래스로 만드는 과정에서의 어려운 점 : 자식 메시지의 공통화
- 메시지의 경우 공통적인 내용이 많다. 그리고 그러한 것을 공통화 하는 것은 리팩토링의 입장에서 중요하다. 그래서 메시지를 공유할 수 있는 클래스 helper를 만든다고 가정하자.
- LookUp 은 부모 메시지이며 Helper는 자식 메시지이다.
@Data
@Component
public class LookUp {
private final CommandValue commandValue = new CommandValue() {
};
private final Helper helper = new Helper() {
};
}
@Data
@Component
public class Helper {
private String introduce;
private String offer;
}
- 그런데 만약 UploadExcelFile 이란 부모 메시지를 만들고, Helper 에 AcceptFileType 이란 명령을 추가하고 싶다. 그래서 아래와 같이 수정했다.
``` java
@Data
@Component
public class UploadExcelFile {
private final Helper helper = new Helper() {
};
}
@Data
@Component
public class Helper {
private String introduce;
private String offer;
private String acceptFileType
}
- 그러면 Lookup에서는 아래와 같은 메서드를 사용할 수 있다.
telegramCommandProperties.getLookUp.getHelper.getAcceptFileType();
- 정말로 이상한 메서드가 동작하게 된다.
그래서 메시징처리는 어떻게?
- 사실 메시징 처리는 까다롭다. 그냥 message.properties 파일을 클래스로 자동생성해줄수는 없을까? @Valid 의 경우 어느 정도 통합이 되어 있으나, 그 이외의 경우는 그렇지 않다.
- 결과적으로 컨텍스트의 빈과 리소스 간의 바인딩 과정에서의 한계는 계속 존재할 것이다. 어떤 식으로든 쉽지 않은 문제이다.
- 차후에는 아래처럼 메시지를 넣는 방식을 시도할 것 같다. 아래의 방법을 할 경우 properties를 운영 도중에 변경할 수 없지만, 그래도 더 직관적이지 않을까 싶다.
public class Lookup{
public static final String HELP_INTRODUCE =
"원하는 데이터를 검색합니다. 명령어와 값은 다음과 같이 입력합니다. -l {원하는 단어} ";
{... 코드 뭉치 ....}
}
- 테스트 코드 작성도 쉬울 것 같다. 해당 클래스의 필드값 전체를 탐색하여 null 이 있으면 뱉어내면 되니까.