주의: 여기에서 Kotlin의 static이란 익명 객체나 최상위 선언의 멤버를 의미합니다.
이러한 서비스의 대입은 전역 상태에 영향을 미치며 애플리케이션을 제거하고 다른 애플리케이션을 설정할 수 없게 만듭니다. 따라서 같은 프로세스 내에서 반복되는 테스트가 실패할 수 있습니다. 유일한 예외는 더미/디폴트 인스턴스를 저장하기 위한 명시적 생성자 호출입니다.
서비스 저장을 피하기 위해 권장되는 방법은 서비스를 로컬로 받는 것입니다.
또는 java.util.function.Supplier으로 래핑(Java, Kotlin)하거나 프로퍼티를 함수로 변환(Kotlin)할 수도 있습니다.
예(Java):
// 좋지 않은 방법:
private static final ManagingFS ourInstance = ApplicationManager.getApplication().getService(ManagingFS.class);
// 좋은 방법:
private static final Supplier<ManagingFS> ourInstance = CachedSingletonsRegistry.lazy(() -> {
return ApplicationManager.getApplication().getService(ManagingFS.class);
});
// 예외:
private static final UniqueVFilePathBuilder DUMMY_BUILDER = new UniqueVFilePathBuilder()
백킹 필드 없이 프로퍼티에 서비스를 대입해도 앞서 언급된 문제가 발생하지는 않지만, 명시적인 getInstance() 메서드를 사용하여 서비스를 가져오는 것이 프로퍼티를 사용하는 것보다 좋습니다.
MyApplicationService.getInstance() 호출이 Kotlin 및 Java 모두에서 활용될 때 일관성이 유지됩니다.MyApplicationService.getInstance()가 MyProjectService.getInstance(project)와 일관성을 갖습니다.도구의 성능을 개선하려면 항상 명시적인 메서드 반환 타입을 유지하는 게 좋습니다.
예:
@Service
class MyApplicationService {
companion object {
@JvmStatic
val instance: MyApplicationService // 나쁨
get() = service()
}
}
@Service
class MyApplicationService {
companion object {
@JvmStatic
fun getInstance(): MyApplicationService = service() // 좋음
}
}
2023.3의 새로운 기능