2013-03-16 3 views
2

나는 모두 Shape 기본 클래스를 확장하는 여러 객체를 가지고 있습니다. 모든 객체에 대해 다른 객체를 표시하려면 editor, 예를 들어 LineRectangle이 아닌 다른 속성을 편집해야합니다. Shape의 모든 구현을 위해 오브젝트 인스턴스에 따라 사용자 정의 편집기를 디스패치하기위한 디자인 패턴은 무엇입니까?

class Shape; 
class Line extends Shape; 
class Rectangle extends Shape; 

List<Shape> shapes; 

void onEditEvent(Shape shape) { 
    new ShapeEditorPopup(shape); 
    //how to avoid instanceof checks here 
} 

은 하나의 단일 Editor 구현이있다. 셰이프 구현 유형 ( instanceof)에 따라 모양에 적합한 편집기를 표시하려면 어떤 패턴을 사용할 수 있습니까?

Shapes (도메인 모델) 스스로가 올바른 편집기가 무엇인지 알고 싶지는 않습니다.

StrategyPattern 여기서는 onEditEvent()에서와 같이 사용할 수 없으므로 모양이 어떤 구현인지 알고 그에 따라 전략을 전달해야합니다.

VisitorPattern

내가 Shapesedit(IEditorVisitor) 메소드를 구현하도록 강제 interface Visitable의 어떤 종류를 구현하는 것 여기에 사용하고, 이것에 의해이 UI에 표시되는 방법에 대한 정보를 도메인 모델을 오염 할 수 없습니다.

그 밖의 다른 조치는 무엇입니까?

업데이트 :. 나는 (내가 edit(editor) 방법 같은 것들을 사용하여 도메인 모델을 "오염"을 가지고 나는 그것을 좋아하지 않아하지만 방문자 패턴에 거라고 방법

예 내가 좋아하는 것 나는 (IEditorVisitor) 메소드 모양이 편집을 구현하도록 강제 인터페이스의 어떤 종류의 참관을 구현하는 것 같은

interface Editable { 
    public void edit(IEditor editor); 
} 

public interface IEditor { 
    public void edit(Shape shape); 
} 


class Line extends Shape implements Editable { 
    @Override 
    public void edit(IEditor editor) { 
     editor.edit(this); 
    } 
} 

class EditorImpl implements IEditor { 
    void edit(Line line) { 
     //show the line editor 
    } 
    void edit(Rectangle rect) { 
     //shwo the rectangle editor 
    } 
} 

답변

3

비지터 패턴 여기에 사용할 수 없습니다.이 문제를 방지하고, 이것에 의해 도메인 모델을 오염하는 그것에 관한 정보와 함께 UI에 표시됩니다.

음, 아니 그것을 표시하거나 편집하는 방법에 대한 도메인 모델 정보를 제공 할 필요가 없습니다. 방문한 도메인 모델 지식 만 제공하면됩니다.

그냥 당신의 방문자 인터페이스 IEditorVisitor의 이름을하지 않으며 IVisitable 방법 edit의 이름을 지정하지 않습니다.

방문자는 이런 종류의 문제에 매우 적합합니다.

내가 더 좋아 할 것 : 편집의 기능은 에디터가되도록이, 이름 만 변경 구현 스케치 본질적으로 같다고

public interface IVisitableShape { 
    void accept(IShapeVisitor v); 
} 

public interface IShapeVisitor { 
    void visit(Line line); 
    void visit(Rectangle rectangle); 
} 

public class Line extends Shape implements IVisitableShape { 

    @Override 
    public void accept(IShapeVisitor v) { 
     v.visit(this); 
    } 
} 

public class EditorImpl implements IShapeVisitor { 
    public void visit(Line line) { 
     //show the line editor 
    } 
    public void visit(Rectangle rect) { 
     //show the rectangle editor 
    } 
} 

참고.

이 패턴의 설명에 함수 이름이 acceptvisit이 일반적으로 사용되며 패턴을 반영합니다. 그들은 물론 변경 될 수 있지만, 필요성을 알지 못합니다. 편집 기능에 명시 적으로 연결되는 것을 방지하는 것이 좋습니다.

+0

글쎄,'edit' 이외의 메소드의 이름을 지정하는 것은 실제로 객체를 편집하는 * 것에 대한 의미가 없습니다. 어쨌든, 나는 나의 대답을 업데이트했다. 그게 당신이 제안하는 것입니까? 여전히 내 도메인 개체의 모든 편집 대리인을 제공해야하므로 그다지 행복하지 않습니다. – membersound

+0

방문자의 구체적인 구현에 함수 별 이름을 지정합니다. 그리고 개체 편집 이외의 기능을 수행하는 다른 방문자를 만들 수 있습니다. –

+0

이 점에 대해 좀 더 구체적으로 설명해 주시겠습니까? 나는 이것을 얻지 못했습니다 ... – membersound