With regards the importance of maintainabillity, is it necessary to envisage no future changes to our classes by the ficitious Junior programmer, or that they will be allowed to modify & recompile the class?
For instance a GUI container, should it be written with a bias towards protected getters to leave everything open to a subclass, or is it okay to assume a complete rewrite since a couple of combos, a few labels and a button does not ammount to a great development investment.
I am thinking specifically of the GUI but this applies throughout.
For once, I'll say "Keep It Simple!" myself . When related to business functionality, a GUI class is very unlikely to be subclassed one day.
Joined: Sep 23, 2003
The GUI part of the assignment states
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.
Concerning the word framework, I was thinking to implement the following to meet this requirement.
I only need to have 2 fields for the criteria component. I'm assuming that future fields will be JLabel/Component pairs so I'll have a class that marries these. Then have a Spring layout that respects a resizing for text fields but keeps preferred size for other components. This way adding new pairs to the container is straightforward. I will still provide accessors to retrieve the pairs I have implemented, for alternative uses. Some layout I will fix - resizing will not affect vertical.
Further thought regards card layout. This could be used to allow easier future development by addtion of further screens. Does this establish a framework?
Really my big question is 'what does establish a framework' really mean?
Joined: Jun 02, 2003
Both your ideas are just great IMO. I personally like very much the abstraction you put in the GUI representation of the search criteria.