Some thoughts on learning + primary key, packages, toString(), static initialization

[Paul Mrozik]

First of all I'd like to thank everyone here who had helped me before. I've been on the Learning Java Path for almost 7 months now and at the beginning of this month I finished my first working project which uses database connectivity, XML Transformations, Swing, JavaMail, and probably a lot of other stuff I didn't know much about earlier. Anyway, the program I made is functional and does what it's supposed to but it...sucks. It's just not tidy enough and although it's not too difficult to follow, I'm starting from scratch and making it bigger and better.

I do have to say that apart from reading books, it was the forum answers and working on my own project that helped me the most. Books are great, but until you get your hands dirty, it's difficult to connect the dots. The new project I'm working on uses inheritance and so things like calls to super(withparams) and polymorphism begin to align and you say to yourself, "Oh, so this is how it works." The knowledge was there beforehand, but it just didn't click. I used to want to get things done just right the first time and I'd never get anything done. Now I'm just inching forward with trial and error/learning and actually accomplishing something.

Anyway, so I'm here to ask more questions.

1. Primary keys

Okay, so this isn't strictly Java, but does it make sense to use a VARCHAR as a primary key if the table is a word table? Or should I be using a PK INT and VARCHAR word combo? The database is embedded (Apache Derby), it's a single user application and there will be as many words as there are in a particular language. Not a huge database, single-user, so performance will probably not be an issue either way, but just curious.

2. Packages

My project is getting bigger. I've set up GIT for versioning and all is well, but there are just too many classes in the tree so I've decided to break them up into different packages as such:

com.somepackage.Package

and

com.somepackage.Package.Subpackage

The problem is that I've given most classes in Package default access and so Subpackage code can't see them. I could just make them public, but I'm thinking - how is this usually done? I mean, I don't want a tree with 20+ classes, I want to group them.

3. toString() and Swing components

Let's say I have a JTree and I need to load people's names from a database. So the Person class mirrors the db structure and a new Person object is created for each database Person record and added to a collection.

Now I want all those people in the JTree, but if I use Person references to create DefaultMutableTreeNode objects, the tree list will be a list of toString() calls. So what if the toString() also lists an address, e-mail, phone number? I don't want that. I just want lastName, firstName on the list.

Here's how I did it before, but I don't like it:

1. The list would show personID, lastName, firstName
2. To get to the person object, the program would parse personID and retrieve the appropriate person from the collection.

I'd like to have direct access to Person. I could modify the toString(), I could also parse the toString() to get the firstName and lastName, but it all seems so clunky to me. Surely there must be a better way.

4. Enum singleton initialization

I used the enum singleton pattern to get access tp the Apache Derby embedded database. The enum is called DerbyDB and there's an INSTANCE in there. The problem here is that the database connection is opened when DerbyDB is first accessed, but I want it to load with the program and perform appropriate initialization. I've read about static initializers and think it might be the way to go, but I'm not exactly sure how to do it.

So I suppose that's it. As always, all input and constructive criticism are greatly appreciated.

[Tim Cooke]

Hi Paul, I don't have answers for all of your questions but I do have one point of feedback.

It's just not tidy enough and although it's not too difficult to follow, I'm starting from scratch and making it bigger and better.

All professional developers have this thought at least once (a month) about the project their working on. The desire to throw it all away and start again can be very compelling. However, in my experience this is almost always the wrong approach to take. Don't underestimate the value in having working software, no matter how ugly it looks under the skin. The answer here is to Refactor, which is "a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior" (refactoring.com). Improve your existing code a little at a time. If you think "I could improve this thing over here if I did x to it" then create a test harness around that part to verify its functionality, then go ahead and make the improvements. Once you've finished then if your test cases still pass then you know you haven't broken any functionality and now you have cleaner, nicer, code. Winner! Do this again and again for other parts you're not happy with and over time you'll see your codebase become a much nicer place to work in. The practice of refactoring is an extremely valuable skill to have as a professional developer as you'll always have to work with unpleasant legacy code at some point or another.

[Paul Mrozik]

Tim Cooke wrote:Hi Paul, I don't have answers for all of your questions but I do have one point of feedback.

It's just not tidy enough and although it's not too difficult to follow, I'm starting from scratch and making it bigger and better.

All professional developers have this thought at least once (a month) about the project their working on. The desire to throw it all away and start again can be very compelling. However, in my experience this is almost always the wrong approach to take. Don't underestimate the value in having working software, no matter how ugly it looks under the skin. The answer here is to Refactor, which is "a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior" (refactoring.com). Improve your existing code a little at a time. If you think "I could improve this thing over here if I did x to it" then create a test harness around that part to verify its functionality, then go ahead and make the improvements. Once you've finished then if your test cases still pass then you know you haven't broken any functionality and now you have cleaner, nicer, code. Winner! Do this again and again for other parts you're not happy with and over time you'll see your codebase become a much nicer place to work in. The practice of refactoring is an extremely valuable skill to have as a professional developer as you'll always have to work with unpleasant legacy code at some point or another.

Thanks for your input Tim. The code base is rather small in my original project and moving it over to the new one is really not an issue, but I would not do this with the current project as it would take way too much time. The refactoring idea is a great one, sounds like The Toyota Way.

[Ivan Jozsef Balazs]

Primary keys

It depends on your requirements. My colleagues making the database development in our shop almost always use an auto-incremented integral primary key, if the business logic does not suggest a natural primary key. But your requirements might differ.

If there are some accompanying pieces of information, making the word itself the primary key in the table might make sense, if it is sought by after the word and you need an index anyway.

[Paul Mrozik]

Ivan Jozsef Balazs wrote:

Primary keys

It depends on your requirements. My colleagues making the database development in our shop almost always use an auto-incremented integral primary key, if the business logic does not suggest a natural primary key. But your requirements might differ.

If there are some accompanying pieces of information, making the word itself the primary key in the table might make sense, if it is sought by after the word and you need an index anyway.

Thank you Ivan. Yes, it sort of works like a dictionary so I think I'll keep things as they are and use the word as the primary key.