I’m wondering if it’s possible to use switch statement instead of if-else one in this case. Variables are taken from JComboBoxes and processed by ActionEvent here:
public void actionPerformed(ActionEvent event) {
Object source = event.getSource();
if (source == comboUnit) {
String unit = comboUnit.getSelectedItem().toString();
if (unit.equals("Unit 1")) {
unitValue = Double.parseDouble(tfUnit.getText());
valMeter = unitValue * defined1;
labelDesc.setText("Unit 1");
convert();
}
else if (unit.equals("Unit 2")) {
unitValue = Double.parseDouble(tfUnit.getText());
valMeter = unitValue * defined2;
labelDesc.setText("Unit 2");
convert();
}
(...)
I was trying to pass pure strings as the values but with no success. Do you have any hints on how it should be done (and if it’s even possible)?
Java 7 allows you to
switchonStrings.Your code needs refactoring though, and the question of whether to use
switchor enumerations or maps, is something that comes second, I would say.You have too much duplicated code doing essentially the same thing. I am referring to:
Obviously, because you multiply using different factors depending on the unit used, you need a function of unit evaluating to the factor to use. In less mathematical terms, you need something that yields value of either
defined1ordefined2depending on a string supplied. You already have theunitreferring to the "name" of your unit in question, you can use it. I call the method returning the factor forfactor, taking in a unit name and returning aNumber(since it does not follow from your example whether you are multiplying integers or real numbers of some sort). I am also assuming yourdefined1anddefined2etc, are variables or literals.The method itself is where your "to switch or not to switch" problem creeps in. You are free to use a map if you want:
Or you can use enumerations:
You can even
switchor use a map inside enumerations, which will give you good code readability as well.You need to profile your program to see if you need
switch-based solution or enum-based one or a map-based one. The way it currently stands and as you can see for yourself, theenum-based solution is a bit messy because of relationship between your unit names, enumeration constants, and their values. If someone can do better with enums, then take their code instead, naturally.Usually, shortest code is best, as it is easier to read and most often understand. But be careful with maps – they induce more overhead than other solutions, so I for one prefer to use them where I have fewer maps with many keys each, not the other way around.