2016-04-05 15 views
-1

MVPパターンを実装しようとしています。私がやっていることがMVPパターンとして受け入れられているかどうかを知りたいのです。状態に基づくMVP更新ビュー

たとえば、3つのボタンと4つのラベルがあるとします。各ボタンは状態にもマッピングされます。たとえば、button1はstate1に、button2はstate2に、button3はstate3にマップされます。各ボタンをクリックすると、State Managerクラスで保持されているアプリケーションの状態が変更されます。 State Managerクラスは、オブザーバパターンを使用して、オブザーバに状態が変更されたことを通知します。

私の見解では、ユーザーの入力を受け取ります。この場合はボタンをクリックし、すぐにイベントをプレゼンターに渡します。だから私はこのようなことをするかもしれない。

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

それから私は、次のようなプレゼンターにする方法があるかもしれません:

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

を今の状態のマネージャクラスは、その状態を変更し、そのオブザーバーに通知します。 は、だから私は持っている私のプレゼンタークラスで:

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

その後、私のビュークラスで私はSTATE1方法があります:メソッドの

@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); 
} 

すべてを異なっています。たとえば、state2は次のようになります。

したがって、ビューは自分自身をレンダリングする方法についての知識を持っているため、これはパッシブビューの実装とは見なされません。それは実際に監督コントローラではなく、モデルにバインドしないためです。明らかにいくつかのプレゼンテーションロジックを持っています。私はそれを完全に取り除き、それを受動的な視点にしようとしましたが、自然な感じではありませんでした。私プレゼンターで

の多くを必要と

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

しかしビューでクラス

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

、:たとえば、私はそれを、私は次のことをやった受動的なビューを作成しようとしたときこれを処理するメソッド。私はプレゼンテーションモデルのパターンも試しましたが、それだけをさらに掘り下げてしまったと感じました。

私の見解では少しのプレゼンテーションロジックが残っていますが、私の実装は好きです。私の実装は依然としてMVPに役立つでしょうか?私はパターンが解釈されることを認識していますが、私の見解では少量のプレゼンテーションロジックを残しても大丈夫ですかどうか不思議です。

答えて

2

あなたの実装は非常にMVPだと思います。もし私がそれを分類しようとするならば、あなたが参照しているデータバインディングの仕組みにかかわらず、監督当局の変種になる傾向があります。プレゼンターとビューとのやりとりが非常に「マクロ的」なので、私はこれを言う。私の場合、パッシブビューバリアントにはもっと多くの「ミクロ」な相互作用があります。

一般的に、ビューに固有のものだけに関連するロジックがある場合は、それは受け入れられるものです。たとえば、項目のリストはListBoxとして1つのビューに表示され、同じインターフェースを実装する別のビューではListViewのように表示される場合があります。したがって、関連するビューのみが各コンテキストで何を意味するのかを知ることになります。 MVPデザインのための私の「Litmus Tests」の1つは、コンソールを使ってビューを表現できるかどうかです。これが現実になるかどうかにかかわらず、デザインと抽象レベルを正しく得ることができます。

さらに、ビュー内のロジックは自動的にtestabilityを減らしません。

MVP設計で常に覚えておくべきもう一つのことは、テスト容易性です。このパターンの重要な目標の1つは、自動テストをサポートすることです。あなたのデザインで、フィーチャー/ユースケースの動作を自動化された方法で完全にテストすることができれば、IMHO、あなたのデザインは良いです。

関連する問題