Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have the following problem. My UI interace contains several buttons, labels, and other visual information. I am able to describe every possible workflow scenario that should be be allowed on that UI. That means I can describe it like this - when button A is pressed, the following should follow ->

In the case of that A button, there are three independent factors that influence the possible result when pushing the A button. The state of the session (blank, single, multi, multi special), the actual work that is being done by the system at the moment of pressing the A button (nothing was happening, work was being done, work was paused) and a separate UI element that has two states (on , off)..This gives me a 3 dimensional cube with 24 possible outcomes.

I could write code for this using if cycles, switch cycles etc....but the problem is, I have another 7 buttons on that ui, I can enter this UI from different states..some buttons change the state, some change parameters... To sum up, the combinations are mindbogling and I am not able come up with a methodology that scales and is systematically reliable. I am able to describe EVERY workflow with words, I am sure my description is complete and without logical errors. But I am not able to translate that into code. I was trying to draw flowcharts but it soon became visually too complicated due to too many if "emafors". Can you advice how to proceeed?

share|improve this question
add comment

4 Answers

up vote 4 down vote accepted

don't try to combine everything in one place

if a button changes a parameter let it change the parameter (and nothing else)

if a button uses a parameter let it request the parameter

this is called limiting responsability

edit: the fact that you are trying to visualize all the possibilities of one action into a cube is an indicator of trying to look too broadly at your program flow. many times there will be similarities between those outcomes (for example blank state means nothing should happen regardless of what the other parameters are)

also try to decentralize the code the OOP approach for this is: each state has it's own code to execute when button A is pressed; have a interface State with the method buttonAPressed() (add parameters as needed) that handles everything specific to the state and implement it differently for blank, single, multi, multi special

share|improve this answer
    
Can you please elaborate a little more on your first sentence? –  Earl Grey Apr 2 '12 at 13:48
    
@EarlGrey I added some clarification –  ratchet freak Apr 2 '12 at 14:23
1  
I followed advice, and after studying all 24 possible outcomes/scenarios, I realized that only 6 of them make sense/are desirable. There is no point of allowing the rest nor making any code for them. Furthermore, After I made a diagram of those 6, I began to see that when looking at detailed operations in all scenarios, there are two operations that are common to all 6 scenarios, so I refactored them. In the end, I ended up with about 20 lines of code. –  Earl Grey Apr 3 '12 at 16:07
add comment

Sometimes, with complex functionality comes a complex implementation. Since the reaction of your UI to user input depends on so many variables, you may just have to accept that your code is not going to be short, sweet, and simple.

You may have to have a separate function to handle each UI component and encapsulate it that way. So, each of these functions acts as an event handler that looks at what is going on in the environment before acting on the user's input.

Another option is to code each UI component as a separate class that perhaps specializes and inherits from a common UI component class. That way, each UI component has its own properties, methods, and state. This may be the best solution to mitigate the complexity of your design.

share|improve this answer
add comment

If you are looking for a formalism, check some graphical approaches:

Many others exist.

I would put the whole state logic in a controller and the UI itself in a view, using a model-view-controller architecture.

share|improve this answer
    
I should have mentioned that I am developing in objective C, for iOS. I respect the MVC pattern, it's done the way you describe. I handle the button events in viewcontroller. This viewcontroller talks to other custom written business logic objects, like for example session manager etc. –  Earl Grey Apr 2 '12 at 13:15
add comment

the problem is, I have another 7 buttons on that ui, I can enter this UI from different states..some buttons change the state, some change parameters... To sum up, the combinations are mindbogling and I am not able come up with a methodology that scales and is systematically reliable. I am able to describe EVERY workflow with words, I am sure my description is complete and without logical errors. But I am not able to translate that into code.

Seems like you should look into the state pattern or the mediator pattern. If your program has all of these states already, imagine how many it might have after 2-3 more years of added features.. You will be able to add new transitions and states easily if you follow the state pattern.

Design patterns actually apply really well the more complex the problem is. Having the foresight to see extendability problems and trying to apply one that fits will payoff in the future.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.