It's not a secret anymore!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Maintainabillity Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Maintainabillity" Watch "Maintainabillity" New topic
Author

Maintainabillity

mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
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.


SCJP 1.4, SCJD
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17250
    
    6

Yes.

Meaning, you have no idea what that Junior Programmer will be required to do. So you code should be maintainable and extensible by anyone. So consider this in your choices.


Don't assume that the GUI would be re-written, subclassed, or changed, it could be none, one, two , or all happen.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Thankyou
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Mike,

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.

Regards,

Phil.
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
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?
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Mike,

Both your ideas are just great IMO. I personally like very much the abstraction you put in the GUI representation of the search criteria.

Regards,

Phil.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Maintainabillity