다형성보기 용 패턴

Question

상상해 보겠습니다. 여러 가지 구체적인 구현이있는 추상 "FriendEvent"모델이 있다고 가정 해보십시오. FriendPosted, FriendCommented, FriendUploadedPhoto 등이 있습니다. 모두 FriendEvent의 내보기에서 렌더링되어야하지만 서로 시각적으로 구분되어야합니다 (예 : FriendUploadPhoto에 미리보기 이미지가 포함되어야 함).

이것을 달성하기 위해 좋은 객체 지향 패턴은 무엇입니까?

보기 코드에서 모델의 구체적인 클래스를 전환하는 대안이 있는지 배우고 싶습니다. 그것은 내가 다형성에 의지하는 것이 가능해야한다고 생각하는 조건부 논리를 사용하기 때문에 어떻게 든 잘못되었다고 생각합니다. 그러나 나는 더 좋은 생각을 생각하기가 힘듭니다. 이것을 처리 할 수있는 확립 된 패턴이 있습니까?

(나는 분명히 그 책임을 혼합 할 것이기 때문에, 모델의 뷰 로직을 구현하고자, 나는 각 모델에 대해 서로 다른 견해가 할 수 있기 때문에하지 않음) 명확하게

을 방법 : 모델 계층에서 다른 이벤트 유형을 모델링하는 것은 문제가 아닙니다. 몇 가지 잘 알려진 OO 솔루션이 있습니다. 질문은 모델을 시각적으로 표현하는 책임이있는보기 코드와 관련이 있습니다. 나는 이벤트 (모델) 보여주기를 다루는 EventView 클래스가 있다고 상상한다. 질문 : 이벤트의 구체적인 유형에 따라 다른 코드 경로를 선택하는 스위치 블록없이이 클래스를 구현하는 방법이 렌더링됩니다.

Answer 1

DoubleDispatch 우려 사항이 여기에 있습니다.

정확하게 이해하면 모델과보기를 혼합하지 않으려 고합니다. 각 이벤트 클래스는

HtmlString getHtmlView() { /* code */ } 

을 가질 수 있지만, 모든 이벤트는보기 지식과 우리가 새로운 getXXXView() 메소드를 추가 뷰의 새로운 종류를 추가 할 때마다이있다. 나는 이것이 불쾌하다고 생각한다.

그래서 우리는 모든 이벤트는 적어도 우리는 자신의 클래스로보기 코드 밖으로있어 이제

HtmlViewMaker getHtmlMaker { return new MyKindOfViwer(this); } 

을 제공함으로써 문제의 분리를 증가시킬 수있다. 예, 각/여러 종류의 이벤트에 대해 특수 사례 코드를 작성해야 할 수도 있지만 불가피합니다. 우리의 첫 번째 문제는 그 특별한 코드를 어디에 넣을 것인가하는 것입니다.

그러나 우리에게는 여전히 문제가 있습니다. 새로운 종류의 View에는 새로운 getXxxMaker 메소드가 필요합니다. 그래서 우리는 더 복잡한 공장들과 Generics와 Templates의 사용 등을 살펴보기 시작합니다.

Answer 2

나를 위해, 나는 단지 부분보기 개념을 사용할 것입니다. 기본 클래스는 기본보기에 의해 처리되며 기본보기에는 구체적인 클래스를 표시해야하는 필요성을 처리하는 부분보기가 필요합니다.