This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Wrapping up Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Wrapping up" Watch "Wrapping up" New topic
Author

Wrapping up

Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
hi

I'm reviewing my code before wrapping up and in doing some open questions popped up:

1 - I have a suncertify.ui package with many subpackages (suncertify.ui.booking, suncertify.ui.configuration, suncertify.ui.launch): looks ok or overdone?
=> I prefer well defined scope. True as well for my code: I like to write small methods communicating their purpose even if they don't do crazy stuff. => both make maintenance easier IMHO

- The ExceptionLogger class: used through the app to report misbehavior/exception for debugging purpose => currently output to System.err a meaningful String (created from the given message and exception). Print a stack trace in System.err as well. This class allows to easily change the way this output is done.
2. isn't the name/purpose too crappy?

- The Message class:
-- contains all the application text shown
3.1 even if it's public static field, I didn't comment each of them, kind of contradicting the rules => ok ?
3.2 each message prefixed with its content of use (for example CONFIGURATION_EDIT_) => ok?

- I put javadoc comments on all fields/methods, without caring for visibility. Indeed the IDE often uses these javadoc anyway when working on the code => helpful
4. not crazy ?

- in my BookingWindow class, I've a BookingAction inner class which is an ActionListener for the book button on the BookingWindow but as well for the ok/cancel of the confirmation asked after through a dialog.
5. Do you think I should separate this ?

- I went for a DatabaseManager interface, of which an implementation is asked for the DbAccessDispatcher (DbAccess implementation). As you can guess by its name, the DatabaseManager is a pretty generic interface. It's so throwing DbException but also... RecordNotFoundException as defined in my DbAccess interface. As such, the RecordNotFoundException isn't a subclass of DbException, whereas it shoud be IMHO. Shall I go the extra length and create a DbRecordNotFoundException, which would then be catched and wrap in the DbAccesss's RecordNotFoundException ?
6. I fear I'm overdoing it... what do you think ?

I hope you don't mind too much these questions. Actually I could have gone without asking them but I like to discuss such matters (there's always stuff to learn), hence the topic...

thanks in advance and... off to bed !

norbert
David Byron
Rancher

Joined: Jan 20, 2009
Posts: 171

Norbert Lebenthal wrote:
1 - I have a suncertify.ui package with many subpackages (suncertify.ui.booking, suncertify.ui.configuration, suncertify.ui.launch): looks ok or overdone?

It's possible to overdefine namespaces. Whether you're doing that or not depends, in part, on how many classes you have in the deepest packages. If you're approaching one package per class, you're probably taking it too far. ;)

Some subpacking is desirable, of course. Use your judgment and justify your choice in the usual place.

The ExceptionLogger class: used through the app to report misbehavior/exception for debugging purpose => currently output to System.err a meaningful String (created from the given message and exception). Print a stack trace in System.err as well. This class allows to easily change the way this output is done.
2. isn't the name/purpose too crappy?

Many people have passed with no logging at all. Some who used logging during development turned it off for the submission. If you include logging, you'll probably want to be sure to demonstrate your awareness of the java.util.logging api. Beyond that, I'm not sure it makes a difference.

- The Message class:
-- contains all the application text shown
3.1 even if it's public static field, I didn't comment each of them, kind of contradicting the rules => ok ?
3.2 each message prefixed with its content of use (for example CONFIGURATION_EDIT_) => ok?

I commented every constant individually.
I'm not sure about your prefixing convention.

- I put javadoc comments on all fields/methods, without caring for visibility. Indeed the IDE often uses these javadoc anyway when working on the code => helpful
4. not crazy ?

I commented all methods, the public ones formally and thoroughly and the private ones more casually. So I hope it's not crazy!

- in my BookingWindow class, I've a BookingAction inner class which is an ActionListener for the book button on the BookingWindow but as well for the ok/cancel of the confirmation asked after through a dialog.
5. Do you think I should separate this ?

An action implies identical functionality (and text and mnemonics and icons) reached through several avenues of approach. Does your app do the same thing via the book button that it does via the ok/cancel?

It sounds to me like these are discrete functions. You should separate them.

- I went for a DatabaseManager interface, of which an implementation is asked for the DbAccessDispatcher (DbAccess implementation). As you can guess by its name, the DatabaseManager is a pretty generic interface. It's so throwing DbException but also... RecordNotFoundException as defined in my DbAccess interface. As such, the RecordNotFoundException isn't a subclass of DbException, whereas it shoud be IMHO. Shall I go the extra length and create a DbRecordNotFoundException, which would then be catched and wrap in the DbAccesss's RecordNotFoundException ?
6. I fear I'm overdoing it... what do you think ?

I fear you're overdoing it. The required Exceptions must be implemented as described in your instructions. Beyond them, it's probably a good idea to take a minimalistic approach rather than code an elaborate hierarchy of Exceptions.

Good luck!


SCJD 6, OCPJP7, Baroque Potion, G+
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

My answers:

1/ I just have subpackages on the main level: suncertify.db, suncertify.gui,... My gui package contains 18 classes. If you end up with almost more packages than classes, then you are almost going bananas

2/ No instructions about logging or exception handling, so I added a few loggers, mainly for debugging purposes (that's why I didn't remove it from the application). All logging was disabled when I submitted (and could be easily turned on). I believe the only moment I write to System.err (or System.out) when you try to start the application with a wrong mode. I documented this decision too

3.1/ I documented every field, method, class, constant,... So also every constant in Message class.
3.2/ I did that too, because you can have multiple ok-buttons which could have seperate labels

4/ see 3.1

5/ If I understand correctly your BookingWindow contains 3 buttons: book, ok and cancel. All these button use the same ActionListener (called BookingAction). First of all I don't know why you have 3 buttons, I guess 2 is enough (ok and cancel). Secondly I used all seperate (anonymous) inner classes to define my ActionListeners because as already stated by David: each button results in another action (business logic) to be performed, so why putting it all together?

6/ I didn't have that problem, because I didn't use extra classes for implementing my data store


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2258
    
    3

Howdy, Nono!

Champion, some considerations:

- I didn't log anything, since it wasn't required;
- If it was today, I'd use a ResourceBundle to store the messages displayed to the users;
- I myself don't like inner classes, so I didn't have any.

Roel De Nijs wrote:If you end up with almost more packages than classes, then you are almost going bananas


Hum... is it "going bananas" or "going to Bahamas"?


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Norbert Lebenthal
Ranch Hand

Joined: Sep 23, 2010
Posts: 74
1. Packaging: only the ui package has subpackages. Overall, I've as well about 5, 5, 3 and 3 classes in each of these packages. I guess I'll keep it this way

2.1 JDK Logging: actually I don't find a nice way to disable it all. AFAIK I would have to know all my loggers and get them by their string id to be able to tweak their config. Doesn't sound too good.

2.2 ExceptionLogger is in fact an utility class which has just one static method:

in turn this one write, currently, to system.err

the goal is to avoid to have writing to system.err scattered through the app => this way if change is needed just one class is impacted. However I'm unsure about the name of this utility class and, in the end, even its intent.

3.1 About commenting every message, I got your right. Yet considering I've about 70 of them (including some mnemonics, since both are linked) yuck But I guess I've to.

5.1 The BookingAction: since I didn't manage to convey nicely my intent here, I guess this stuff was fuzzy anyway. I've removed the "implements ActionListener" and went for anonymous inner classes going directly at the handling methods I had anyway defined.
5.2 Inner classes: well, in my case they're quite handy since the BookingAction and SearchAction are both heavily linked to the BookingWindow... If I was to make them static or even top level, then I would have to pass at least the BookingWindow (and make extra fields accessible). I feel like it's nicer the current way...

6. Extra stuff with exception: I didn't change my stuff in the end. Thus I've a DatabaseManager interface whose each methods throw DbException and some the required exceptions of my DbAccess. Thus I'll still abiding to the requirements + I'm coding to an interface and not an implementation, making it all cleaner (less coupling) and easier to change if needs be later.

thanks again

I feel like I'm ready for my Essay tomorrow
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5139
    
  12

Good luck! I'm sure you'll do well and will be a scjd in 4-5 weeks.
 
wood burning stoves
 
subject: Wrapping up
 
Similar Threads
Best practices for writing javadoc for a Spring-style web application?
NX: Should I reformat the provided interfaces comments?
B&S: Hiding DBMain implementor
URLyBird : Need Suggestions on create method and update method
NX: (Contractors) Interfaces and design question