Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The first thing I noticed about your example was that State 3 = (State 1 == true &amp;&amp; State 2 == true). This will not scale very well as more possible states become involved. If you are only considering whether it is raining or whether it is Sunday, you can have an enumeration like this, with 4 possible types:</p> <pre><code>enum State { CLEAR_OTHER_DAY, RAINING_OTHER_DAY, CLEAR_SUNDAY, RAINING_SUNDAY } </code></pre> <p>This would allow you to state conditions cleanly in a switch block when it is time to code. But if you have to also consider whether it is warm outside, you have to add 4 more values to that enum to capture all possible conditions. And later in your project, your code may need to capture more conditions than you currently envision.</p> <p>As for a design pattern, the State pattern and its <a href="http://en.wikipedia.org/wiki/State_pattern#Java" rel="nofollow noreferrer">Java example on Wikipedia</a> look like a good place to start.</p> <p>Wikipedia's example has a <code>StateContext</code> class with a method called <code>setState</code> that takes in a name. I thought about suggesting that you add the state determination logic here, but that would make your <code>StateContext</code> class need to get too close to the implementation details of your other classes. It would be better to put a method for determining the system's state in a class that would easily know the conditions for going from one state to another. This way, if your project needs to change in the future and you either have more states to keep track of or different conditions, you only need to maintain the logic in one place.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload