이벤트 큐 항목에 대한 디자인 패턴 요청

Question

지금 제가 가장 좋은 해결책을 생각할 수 없기 때문에 제가 사용할 수있는 디자인 패턴에 관해서 정말로 도움이 필요합니다.

다음 작업을 수행 할 수있는 무언가가 필요합니다. 은 현재 내가 3 개체가 :

NotificationOne.java

NotificationTwo.java

NotificationThree.java

각각은, 기본적으로 같은 일을 나타냅니다를하지만 필드에 올 때 그들이 아무런 공통점이 없다/속성.

이들은 실제로 JMS 대기열을 통해 도착할 때 객체로 매핑 할 일부 JSON입니다.

이제 실제로해야 할 일은 각각의 필드를 특정 방식으로 해석하여이 3 개의 개체를 공통 개체로 변환하는 것입니다. 지금까지 쉽게 할 수 있습니다.

진정한 질문은 시간이 지남에 따라 뭔가가 공통 개체로 변형되어야 할 더 많은 유형의 알림이있을 것이라는 점을 고려할 때 적용 할 수있는 최상의 디자인 패턴은 무엇일까요? ,

-JSON 큐

-I 가능한 공장에 POJO

POJO와 -Pass

에 JSON을 매핑합니다에서 가져옵니다

사물의 흐름은 다음과 같이 될 것입니다 이 클래스는 Notification 클래스의 각 유형을 처리해야하므로 CommonNotification으로 변환 할 수 있습니다.

- CommonNotification가

DB에 저장되어야 -A CommonNotification 특정 필드 통지 페이로드로 사용되어야한다.

이 흐름을 기반으로 할 수있는 최선의 패턴은 무엇입니까?

미리 감사드립니다.

Answer 1

변환 유형은 알림 유형에 따라 다름을 알 수 있습니까? zapl이 말했듯이이 경우 공용 인터페이스를 만들고 세 가지 알림 클래스에서 변환을 수행합니다. 디자인은 매우 간단합니다. 새 알림을 만드는 모든 사용자는 인터페이스를 구현해야하므로 전환을 완료해야한다는 것을 알고 있습니다.

이론적으로 말하면 POJO는 POJO가되어야한다는 것이 맞습니다. 그러나이 경우 필요한 것보다 더 복잡한 디자인을 만들지는 않을 것입니다. 인터페이스와 다형성이 여기에있는 길입니다.

다음으로 공통 알림을 만들면 시스템에 부작용이 없습니다. 따라서 POJO가 시스템 상태를 수정하는 것이 아닙니다. 아주 POJO에 특정한 논리가 있습니다. 그것은 POJO에 속합니다.

Answer 2

장식 패턴을 사용하십시오.

ConcreteDecorator는 원래 구성 요소에 책임을 추가하기 만합니다.

출력마다 다른 장식 데코레이터를 사용할 수 있지만 원래 구성 요소의 책임은 모든 출력에 그대로 있습니다.

는`convertToCommonNotification()`과 같은 방법으로 공통 인터페이스를 구현 POJO를에