R
RedGrittyBrick
In one application I have a long switch statement that looks like this
// Entity is an enum
private JPanel selectView(Entity entity) {
switch (entity) {
case Country:
return new CountryControl().getJPanel();
case Currency:
return new CurrencyControl().getJPanel();
// and so on, dozens of other similar cases
default:
return null;
}
}
Q1)
I can't help feeling that I ought to be able to find a way to eliminate
the switch statement. Ideally one that doesn't just involve transferring
complexity elsewhere.
Any ideas?
This is actually part of a small test application I am playing around
with. My aim is to explore ways to organise the classes of a Swing
application that allows the user to view data from dozens of database
tables.
I'd welcome comments on that too.
It's small but a bit long to post here. 14 classes averaging 45 lines
each (none longer than 82 lines).
http://redgrittybrick.org/java/testMVC2/App.java
http://redgrittybrick.org/java/testMVC2/Controller.java
http://redgrittybrick.org/java/testMVC2/Country.java
http://redgrittybrick.org/java/testMVC2/CountryControl.java
http://redgrittybrick.org/java/testMVC2/CountryModel.java
http://redgrittybrick.org/java/testMVC2/CountryView.java
http://redgrittybrick.org/java/testMVC2/Currency.java
http://redgrittybrick.org/java/testMVC2/CurrencyControl.java
http://redgrittybrick.org/java/testMVC2/CurrencyModel.java
http://redgrittybrick.org/java/testMVC2/CurrencyView.java
http://redgrittybrick.org/java/testMVC2/FormView.java
http://redgrittybrick.org/java/testMVC2/Log.java
http://redgrittybrick.org/java/testMVC2/Model.java
http://redgrittybrick.org/java/testMVC2/View.java
I've abstracted CountryControl and CurrencyControl to the point I don't
need them (App.java half reflects this) but they keep the switch
statement shorter - at the expense of extra classes - I'm torn.
Q2)
Are there major ways I can simplify things or make it more elegant?
// Entity is an enum
private JPanel selectView(Entity entity) {
switch (entity) {
case Country:
return new CountryControl().getJPanel();
case Currency:
return new CurrencyControl().getJPanel();
// and so on, dozens of other similar cases
default:
return null;
}
}
Q1)
I can't help feeling that I ought to be able to find a way to eliminate
the switch statement. Ideally one that doesn't just involve transferring
complexity elsewhere.
Any ideas?
This is actually part of a small test application I am playing around
with. My aim is to explore ways to organise the classes of a Swing
application that allows the user to view data from dozens of database
tables.
I'd welcome comments on that too.
It's small but a bit long to post here. 14 classes averaging 45 lines
each (none longer than 82 lines).
http://redgrittybrick.org/java/testMVC2/App.java
http://redgrittybrick.org/java/testMVC2/Controller.java
http://redgrittybrick.org/java/testMVC2/Country.java
http://redgrittybrick.org/java/testMVC2/CountryControl.java
http://redgrittybrick.org/java/testMVC2/CountryModel.java
http://redgrittybrick.org/java/testMVC2/CountryView.java
http://redgrittybrick.org/java/testMVC2/Currency.java
http://redgrittybrick.org/java/testMVC2/CurrencyControl.java
http://redgrittybrick.org/java/testMVC2/CurrencyModel.java
http://redgrittybrick.org/java/testMVC2/CurrencyView.java
http://redgrittybrick.org/java/testMVC2/FormView.java
http://redgrittybrick.org/java/testMVC2/Log.java
http://redgrittybrick.org/java/testMVC2/Model.java
http://redgrittybrick.org/java/testMVC2/View.java
I've abstracted CountryControl and CurrencyControl to the point I don't
need them (App.java half reflects this) but they keep the switch
statement shorter - at the expense of extra classes - I'm torn.
Q2)
Are there major ways I can simplify things or make it more elegant?