Justin, There isn't "one right way" to do anything. It is a question of what is going to be the clearest to maintain. For example, if you look at this code in two years or if someone else joins the project and reads it, what will make sense.
1) There's no such thing as a private class, so I'll assume you mean a separate class. It is a good practice for the SQL connection string to be separate from the rest of the code. This way you have it in one place in case it changes. Maybe you will change databases in the future. You could use a constant for this string or put it in a property file.
2) When the class gets too long, it means you need multiple classes . Seriously though, think about the major things your program does. Maybe it takes input from the user, does a query and displays it. In this example, you would want all the JDBC code in a separate "data access object" to make the rest of the code more readable. An interface is useful if you want to "mock out" the data object call to test the rest of your code without the database.
If you provide some more detail about what your program does, you may get more useful answers.
You don't need to worry about interfaces if you are just starting out. Just use classes. Later, when your code gets more complex, interfaces are very useful, but you never need them.
Sql strings (query, update, insert, etc.) are just strings. Nothing special. Since Java handles strings well, you can write them once and reuse them, or build them dynamicaly at runtime. Make no difference. And as a beginner, don't worry about performance issues, sure a "prepare" statement is faster than a normal execute() on a Statement, but get the code to work first, then handle performance.
Plus, in 99% of all client/server applications where you Java code talks to some database (say MySql, Oracle, etc.) the time it takes to talk to the remote Database server is far larger and more important than the time it takes to make up the Sql query string.
I generally try to have my functions be under a page long, and classes under a few hundred lines, but these are just guidelines. I've had long functions and monster classes when it makes sense.
Joined: Mar 05, 2007
I don't know how to write a stand alone Java class for a Sql connection. Also, how would I reference that in a program I have to go grab SQL and write it to a text file. In the Main to I just reference the class name like public class SqlConnectionClass. I am lost I appreciate any and all help you provide me.
My programs are usually over 300 lines of code. The other person that responded said I should try to keep them smaller. I don't understand how to do that. How do I get all these little classes to talk to each other and to know what order to read them in? /******************** Remarks ****************************** //Sql Connection //Date: September 7, 2007
Justin, You may want to read an introductory book on design. "Head First Object-Oriented Analysis and Design" is good and easy to read. A book will go into a lot more detail than we can here.
For your specific problem, try to break it down into smaller problems. Refactoring a 300 line program is a bit overwhelming. For example: 1) Extract the code that processes a result set into a method 2) Move that method to another class 3) Instantiate the new class in your original class and call the new method 4) Repeat for each database related section of code 5) When done, you have a data access object
Don't worry about all the little classes talking to each other. It's easier (at first) to have your original program keep all the control. The original program/class becomes a driver that talks to the other/little classes.