파일 시스템 하위 트리의 스냅 샷에 대한 반복자

Question

Java의 파일 시스템 하위 트리를 통해 반복자를 개발해야합니다. 반복이 진행되는 동안 파일 시스템의 상태가 변경 될 수 있습니다 (예 : 새 폴더 및 파일이 생성 및 삭제됨). 따라서 이터레이터는 먼저 계층 구조의 스냅 샷을 캡처 (예 : 트리를 크롤링하고 목록에있는 모든 파일의 이름을 저장) 한 다음 스냅 샷을 반복해야합니다.

이터레이터의 생성자에 캐시를 생성하는 코드를 삽입하는 것이 좋은지 아닌지 궁금합니다. 대안은이를위한 특정 방법을 지정하는 것입니다 (이름은 init).

반복 하위 트리의 크기와 깊이가 커질 수 있으므로 캐싱에 많은 시간이 소요됩니다. 게다가, IOException을 던질 수도있다. (Java의 생성자로부터 예외를 던지는 것이 좋은 디자인 관행인지는 아직 확신 할 수 없다.)

한편, 반복기를 초기화하는 전용 메소드를 작성하면 클라이언트 코드가 반복기를 단순히 Iterator 인터페이스의 구현으로 사용할 수 없음을 의미합니다.

클라이언트 코드는 순회하기 전에 init 메소드를 호출 할 책임이 있습니다. hasNext/next 메서드를 먼저 가질 수 있습니다. 반복기가 초기화되었는지 확인하고 그렇지 않은 경우 init 메서드를 호출하십시오. 그러나 이러한 방법에 대한 첫 번째 호출은 클라이언트 측에서 볼 수있는 이유가없는 다음 호출보다 훨씬 느릴 수 있습니다.

Answer 1

의견에서 말씀 드렸듯이 파일 시스템의 스냅 샷 (예 : FileSystemSnapshot)을 취하는 것과 두 번째 클래스의 책임을 분리하는 방법을 사용했습니다. 필요한 유연성에 따라 반복자의 생성자에 FileSystemSnapshot 인스턴스를 만들거나 생성자 인수로 전달할 수 있습니다. 첫 번째 방향으로 나아가면 클라이언트는 반복기를 구성 할 수있는 유연성이 더 커지며, 예를 들어 파일 시스템 스냅 샷을 가져 오는 다른 전략을 가질 계획이라면 유용 할 수 있습니다. mocks or stubs을 쉽게 만들 수 있으므로 단위 테스트에도 좋습니다. 그러나 클라이언트는 트래버스 세부 정보 (즉, 파일 시스템을 가로 지르기 전에 캐시되어야 함)를 알도록 강요합니다. 두 번째 방법을 사용하면 클라이언트에서이 구현 세부 사항이 숨겨 지지만 유연성이 떨어지며 약간의 테스트가 더 까다 롭습니다 (여기서 createFileSystemSnapshot() 메서드를 정의한 다음 해당 메서드를 조롱하여 테스트에 대한 다른 인스턴스를 반환 할 수 있습니다). dependency injection 패턴을 확인할 수도 있습니다.

HTH는

Answer 2

생성자에서 캐시를 만드는 것이 좋습니다. 시간이 많이 소요되는 부분에 대해서는 반복기를 사용하는 방법에 따라 결정해야합니다. 클라이언트가 캐시가 완료 될 때까지 클라이언트가 반복 할 수 없으면 시간이 걸리는 생성자 또는 init 메소드가 문제가되지 않습니다. 이는 동기화 차단 작업입니다.

캐시가 완료되기 전에 반복을 시작할 수 있다면 캐시를 수행하는 스레드를 시작할 수 있지만이를 고려하려면 hasNext()를 재정의해야하며 hasNext() 또는 다음() 누가 기다리고 남아 있습니다.