MVP Update-Ansicht basierend auf dem Status

Question

Ich versuche, das MVP-Muster zu implementieren, oder meine eigene Interpretation/Variante davon. Ich bin neugierig zu wissen, ob das, was ich mache, als MVP-Muster akzeptabel ist.

Sagen Sie zum Beispiel, dass ich 3 Tasten und 4 Etiketten habe. Jede Schaltfläche wird ebenfalls einem Status zugeordnet. So wird beispielsweise Button1 State1 zugeordnet, Button2 entspricht State2 und Button3 entspricht State3. Jeder Klick auf eine Schaltfläche ändert den Status meiner App, die in einer State Manager-Klasse gespeichert ist. Die State-Manager-Klasse verwendet das Beobachtermuster, um Beobachter darüber zu informieren, dass sich der Status geändert hat.

In meiner Sicht, greife ich die Benutzereingabe, in diesem Fall die Schaltfläche klicken, und dann übergeben Sie das Ereignis sofort an den Referenten. Also könnte ich so etwas haben.

button1.addActionListener(new ActionListener() 
{ 
    public void actionPerformed(ActionEvent e) 
    { 
    presenter.btn1Pressed(); 
    } 
}); 

Dann könnte ich eine Methode, in der Moderator wie folgt haben:

public void btn1Pressed(){ 
    stateManager.setState(state1); 
} 

Jetzt ist der Zustand Managerklasse seinen Zustand ändert und benachrichtigt seine Beobachter. Also in meinem Presenter-Klasse I haben:

@Override 
public void stateChange(State state){ 
    switch(state){ 
    case state1: 
     view.state1(); //view is an interface not a concrete. 
     break; 
    } 
} 

Dann meiner Meinung nach Klasse habe ich die state1 Methode:

@Override 
public void state1(){ 
    button1.setEnabled(false); 
    button2.setEnabled(false); 
    button3.setEnabled(true); 
    label1.setVisible(true); 
    label2.setVisible(false); 
    label3.setVisible(true); 
    label4.setVisible(false); 
} 

Alle Methoden sind unterschiedlich. Zum Beispiel state2 könnte sein:

@Override 
public void state2(){ 
    button1.setEnabled(true); 
    button2.setEnabled(false); 
    button3.setEnabled(true); 
    label1.setVisible(false); 
    label2.setVisible(false); 
    label3.setVisible(true); 
    label4.setVisible(false); 
} 

Daher ist die Ansicht Wissen darüber, wie sie zu machen hat, so würde ich dies eine passive Ansicht Umsetzung nicht in Betracht ziehen. Es ist auch nicht wirklich Supervisor Controller, da es nicht an ein Modell bindet. Es hat offensichtlich einige Präsentationslogik. Ich habe versucht, es komplett zu entfernen und es zu einem passiven Blick zu machen, aber es fühlte sich nicht natürlich an. Zum Beispiel, wenn ich versuchte, es eine passive Ansicht habe ich folgendes zu machen:

In meinem Moderator Klasse

private void state1(){ 
    view.setButton1Enabled(false); 
    view.setButton2Enabled(false); 
    //... 
} 

Nach Ansicht

public void setButton1Enabled(boolean enabled){ 
    button1.setEnabled(enabled); 
} 
public void setButton2Enabled(boolean enabled){ 
    button2.setEnabled(enabled); 
} 
//... 

jedoch, die viel verlangt Methoden, um damit umzugehen. Ich habe auch ein Präsentationsmodellmuster ausprobiert, aber ich fühlte, dass es nur noch mehr muckte.

Ich bevorzuge meine Implementierung, obwohl es ein bisschen Präsentationslogik aus meiner Sicht hält. Wäre meine Implementierung noch für MVP geeignet? Ich merke, dass Muster interpretiert werden müssen, aber ich bin neugierig zu wissen, ob es in Ordnung ist, kleine Mengen von Präsentationslogik zu verlassen.

Answer 1

Ich denke, Ihre Implementierung ist sehr MVP. Wenn ich es klassifizieren würde, würde ich darauf hinarbeiten, dass es die Supervising-Controller-Variante ist, ungeachtet des Datenbindungsmechanismus, auf den Sie verweisen. Ich sage das, weil die Interaktion des Presenters mit der View sehr "Makro" ist. Für mich würde die Passiv View-Variante viel mehr "Mikro" -Wechselwirkungen haben.

Ich finde im Allgemeinen, dass, wenn die Ansicht nur Logik hat, die sich auf Dinge bezieht, die für sie spezifisch sind, dann ist das akzeptabel. Beispielsweise könnte eine Liste von Elementen in einer Ansicht als ListBox dargestellt werden, während in einer anderen Ansicht, die dieselbe Schnittstelle implementiert, die Liste möglicherweise als ListView dargestellt wird.Daher wird nur die relevante Ansicht wissen, was SetState() in jedem Kontext bedeutet. Einer meiner 'Lackmus-Tests' für ein MVP-Design ist, ob ich die Ansicht über eine Konsole darstellen kann oder nicht. Unabhängig davon, ob dies zur Realität wird, finde ich es hilfreich, das Design und die Abstraktionsstufen genau richtig zu machen.

Darüber hinaus reduziert Logik in der Ansicht nicht automatisch testability.

Eine andere Sache, die man bei MVP Design immer im Auge behalten sollte, ist die Testbarkeit. Eines der Hauptziele des Musters ist die Unterstützung automatisierter Tests. Wenn Ihr Design es Ihnen ermöglicht, das Verhalten des Features/Anwendungsfalls auf eine automatisierte Art und Weise mit einer falschen Ansicht zu testen, dann ist Ihr Design gut, IMHO.