아래와 같이 특별한 경우가 있습니다. Listener 클래스와 업 로더 클래스가 있습니다. 리스너 클래스는 네트워크를 통해 메시지를 수신하여 처리하고 그로부터 다른 작은 객체를 만듭니다.스테이트 풀 헬퍼 클래스를 사용하는 것은 나쁜 습관입니까?
public class Listener {
Uploader uploader;
Listener(String location) {
uploader = new Uploader(location);
}
public void listen(Message msg) {
ProcessedObject obj = process(msg);
uploader.add(obj);
}
public void terminate() {
if (null != uploader) {
uploader.finish();
}
}
}
업 로더 클래스는 추가 방법을 통해 하나 개의 객체를 받아, 업 로더시기를 결정한다. 이를 위해 목록을 유지 관리합니다. 또한 하나의 리스너에 특정한 위치 문자열이 있습니다. 요점은 다음과 같습니다.
/**
* This class is not thread safe, and an object should not be shared across threads
*
*/
public class Uploader {
String location;
List<ProcessedObject> objects;
Uploader(String location) {
this.location = location;
}
void add(ProcessedObject obj) {
objects.add(obj);
if (objects.size() > PARTITION_SIZE) {
uploadObjects(objects);
objects.clear();
}
}
void finish() {
uploadObjects(objects);
}
}
따라서 개체 수가 PARTITION_SIZE보다 큰 경우 업로드됩니다. 응용 프로그램에는 여러 개의 리스너가 있으며 각 리스너는 별도의 스레드에서 실행됩니다. 각 수신기에는 자체 업 로더 개체가 있습니다. javadoc에서이 클래스가 스레드로부터 안전하지 않다고 분명히 언급했습니다.
이제 제 질문은 좋은 습관입니까?
동료 중 일부는 이것이 좋은 습관이 아니며 업로드에 정적 방법을 사용하고 업 로더의 인스턴스를 만들지 말라고 권유합니다. 하지만 내 주장은, 청취자 클래스를 지저분 해지게 만들 것입니다. (청취자가 카운트를 유지하고, 나머지 오브젝트를 종료하기 전에 마지막에 확인하고 다시 업로드해야하기 때문에)
제 접근 방식에서는 전체 파티셔닝과 업로드 로직은 업 로더 클래스에서 사용할 수 있으므로 가독성과 유지 보수성이 향상됩니다.
제 질문은 제 접근법이 나쁜 습관입니까 (특히 업 로더가 스레드로부터 안전하지 않다고 명시하는 것도 고려해야합니다).
또한 여기에 내가하려고하는 디자인 패턴이 있습니까? 그렇다면 어느 것입니까?
편집 : 나는 틀린 질문을 제대로 받아들이지 않았다. 나는 여기에서 분할이나 업로드에 관심이 없다. 스레드 당 업 로더 클래스의 객체 하나를 만드는 방법, 정적 메서드로 상태를 유지하는 업 로더 클래스를 만드는 방법.
나머지 개체를 업로드하든, 아니면 전혀 분할해야하는지 여부는이 질문에 대한 우려가 아닙니다.
내가 잘못하지 않았다면, 나는 업 로더 스레드가 정기적으로 모니터링하고 업로드 할 수있는 객체의 공유 목록을 유지해야 할 것입니다. 당신이 제안하고있는 것입니까? – Kartik
@Kartik 그게 가능한 구현 중 하나입니다. 또는 각 리스너 스레드는 연관된 업 로더 스레드를 가질 수 있습니다. 제 요지는 청취자에게 완전히 투명해야한다는 것입니다. –
이것은 실제로 의미가 있습니다. 그러나이 경우에도 파티션을 올바르게 유지해야하는 업 로더입니까? – Kartik