Refactoring Switch/Case Hell into a Simple Factory
I have often found that no matter what amazing system you are using or have set up, there are many times that a good simple factory design pattern will get the product out the door. What do I mean by simple factory you may ask?
Let us say you are wanting to switch between many different charts on the fly and you want your users to be able to select between a Line Chart, a Column Chart, and a Area Chart. You may start your design as something such as:
1 2 3 4 5 6 7 8 9 10 11 12 13 | public function createChart():void{ switch(chosenChart){ case "AreaChart": //code to create an area chart break; case "LineChart": //code to create an linechart break; case "ColumnChart": //code to create an column chart break; } } |
And now you have a function to update the charts
1 2 3 4 5 6 7 8 9 10 11 12 13 | public function updateChart():void{ switch(chosenChart){ case "AreaChart": //code to update the area chart break; case "LineChart": //code to update the linechart break; case "ColumnChart": //code to update the column chart break; } } |
Now let us say that each of those code blocks require 20 lines of code to set up your chart the way you want and another 20 lines of code to update the chart. Well, if you client then say that he also wants to see a pie chart, a bar chart, and a plot chart you have officially doubled your code.
Simple Factory to the rescue.
* I will admit, you will still have a bunch of code, but it will be separated in a manner that is easier to read and manage in the future *
Let us now refactor that code into something that is helpful using our wonderful Interfaces.
First the Interface.
1 2 3 4 5 | //package information public interface IChartView{ function createChart():void; function updateChart():void; } |
Next, a sample chart:
1 2 3 4 5 6 7 8 9 10 11 12 13 | //package information public class ColumnChartView impliments IChartView { public function ColumnChartView(){ createChart(); } public function createChart(){ //code to create the chart } public function updateChart(){ //code to update the chart } } |
Now we can refactor our code from earlier to such:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | public function createChart():void{ var chart:IChartView; switch(chosenChart){ case "AreaChart": chart = new AreaChartView(); break; case "LineChart": chart = new LineChartView(); break; case "ColumnChart": chart = new ColumnChartView(); break; } } |
And what is really nice, is later in our code if we need to update the chart’s data provider or the axis or anything all we have to call is:
1 2 | //your code chart.updateChart(); |
The chart now updates itself. I don’t have to switch/case multiple times to determine how to update my chart and in the future if I want to add another chart (because the client always wants another way to look at the same data) I can just add another Class that implements the IChartView interface and add on more case statements to my first (and only) switch/case statement. Again I say, Yes you will still have lots of code, but the code will be more manageable and readable than it was earlier AND you will only have to use the switch/case statement once to determine which interface implementation to use.
That is a quick and dirty trick to help cut down code and increase the manageability of your Flex projects.
Not really necessary to use switch because I can’t do if (x !=0 ) with it and it doesn’t allow me also to use multiple statements, so U can use switch if everything is equal, but when it comes for non-equality, U’ve stuck.
I completely agree with you that a switch/case logic structure would not be as helpful in that situation. Switch/Case statements are best when you have multiple types and logic flows all based around one structure/variable.