2013-05-20 2 views
1

UDP 메시지를 수신하고 분석하는 시스템 용 API를 구축하고 있습니다. 이제 그 변화에 대해 개발자에게 알릴 필요가 있습니다.Java의 알림 시스템

현재 2 가지 구현을 염두에두고 있지만 어느 것이 더 좋고 다른 옵션이 있는지 확실하지 않습니다.

용액 AArrayBlockingQueue 등이 공회전하는 동안 어떤 전력을 소모하지 않는 것 같다

. API 측면에서 새로운 배열에 대해 알리고 싶을 때 정적 배열을 만들고 메시지를 추가합니다. 그래서 개발자 측에서는 새로운 메시지를 듣기 위해 스레드에 넣을 수있었습니다. 사용자는 메시지를 가져 오는 등 그 유형과 속성을 확인 할

솔루션 B콜백 나는이 솔루션은 더 아름답고 더 조직이 될 것입니다 생각

. 가능한 모든 알림 유형으로 인터페이스를 만들고 개발자가이 인터페이스를 구현할 수 있습니다. API 측면에서 API가 동일한 유형의 수신기를 두 개 이상 알릴 수 있도록 동일한 수신기의 해시 맵을 사용합니다.

더 많은 아이디어 나 제안이 있으십니까?

답변

4

이벤트 기반 시스템의 경우 비동기식 솔루션이 가장 좋습니다. 참고로, 블로킹 솔루션보다 가볍기 때문에 각 이벤트 수신기마다 스레드가 필요합니다.. 따라서 솔루션 B가 선호됩니다.

당신이 알고 있어야 할 사항 중 하나는 스레딩 문제입니다. 당신은 자신의 스레드에서 콜백을 호출하므로 콜백 구현자는이를 처리 할 준비가되어 있어야합니다. 콜백 코드는 특정 스레드에서 실행될 것이라고 가정해서는 안됩니다. 매번 다른 스레드에서 실행될 수도 있습니다.

2

Observer 패턴이 유용 할 수 있습니다. 특히 동일한 주제에 대해 둘 이상의 청취자가있을 수있는 경우 특히 유용합니다.

리스너의 해시 맵을 정의하는 대신 리스너의 CopyOnWriteArrayList를 사용할 수 있습니다. 이 접근 방식을 사용하면 새로운 리스너를 추가해도 리스너에 대한 반복을 방해하지 않습니다.

가능한 모든 알림 유형을 허용하는 인터페이스를 정의하는 대신 모든 가능한 알림 유형의 인터페이스 또는 루트 클래스를 허용하는 단일 메소드로 인터페이스를 정의 할 수 있습니다. 예를 들어,이 인터페이스는 매개 변수화 된 유형 EVENT를 서브 클래 싱하는 모든 이벤트 객체를 수신 할 수 있습니다.

public interface IObserver<EVENT> { 
    public void receive(@NonNull EVENT event); 
} 
+0

OP는 자신의 솔루션 B에서 * Observer *로 간주합니다. "콜백"은 사실상이 컨텍스트에서 "관찰자"와 동의어입니다. –

+1

OP에는 Observer 패턴이 없습니다. 기존 패턴에 대한 지식은 최악의 경우 무해하며 유용 할 수 있습니다. –

+0

나는 그가 패턴을 안다는 것을 아는 5 달러를 걸 것이다. –