Strategy again. This time: Manipulating a View (that has different "Modes")

 
555   99.9
Aug 30, 2011
 
Hi there again,

It's been some time and my last question was aimed at the strategy pattern. I wanted to know how I can make use of this pattern to replace a switch/case with something more SOLID. :)

This time, I would like to know about possible best practices in regards to working with an MVP design.

Assume that you have a WinForms project that contains some views that implement interfaces and presenters that connect them to business objects (models) using databinding.

Assume further that you have a view that is able to be presented in different modes. Depending on the mode selected, specific controls in the view are [dis|en]abled, (in)visible, etc...

Usually you'd see something like this:

Presenter:
Switch Mode
    Case ModeEnum.Mode1
        View.TextBox.Visible = True
        View.Label.Visible = True

    Case ModeEnum.Mode2
        View.TextBox.Visible = False
        View.Label.Visible = False

End Switch

I
However... in my case the base code is even more complicated. The answer to the question of what to do with the controls is based on more than one enum, but also some old fashioned strings that contain further selection criterias.

For example:

Switch Mode
    Case ModeEnum.Mode1
        If Criteria = "Criteria1" Then
            View.TextBox.Visible = True
            View.Label.Visible = True
        Else If Criteria = "Critera2" Then
            View.TextBox.Visible = True
            View.Label.Visible = False
        End If
.
.
.

What I would like to achieve now is implementing a strategy pattern that allows the presenter to call into a context class with the Mode and the Criteria so that the context class can execute a method that manipulates the view accordingly.

Are there any best practices in regards to SOLID?

Other people in my team did something similar. However, they implemented methods within the views that were responsible for manipulating the views' controls and called them from the context class. This however is not OCP. Each time a new mode is added, not only a new strategy needs to be implemented but also a method within the view (you get the point).

So: How do you solve this?

Regards,
Christian.



80   96.1
Oct 06, 2011
Hi Interesting question, 

Will work more on this question and get back but meanwhile..would like to know whats your focus here:

 1) to minimize coding/impact to your solution?
 2) or if it is to have a dynamic solution that could automatically generate Views based on Mode/Criteria?

if yes (for 2 qn then) if there is a new Mode and/or Criteria to be introduced to your app, yes we will have to add the Mode and a relevant method to the class that generates the View.

May be we can think of de-coupling the UI from the class which generates the View various other patterns.

If you already have solution by now, please share.

--Due to space limiation was not able to put in comments field--

Thanks and Regards
Tarriq