views:

62

answers:

3

I am currently writing a java-class that wraps an SQLite database. This class has two ways to be instantiated:

  1. Open an existing database.
  2. Create a new database.

This is what I came up with:

public class SQLiteDatabaseWrapper {
    public static SQLiteDatabaseWrapper openExisting(File PathToDB) {
        return new SQLiteDatabaseWrapper(PathToDB);
    }

    public static SQLiteDatabaseWrapper createNew(File PathToDB) {
        CreateAndInitializeNewDatabase(PathToDB);
        return new SQLiteDatabaseWrapper(PathToDB);
    }

    private SQLiteDatabaseWrapper(File PathToDB) {
        // Open connection and setup wrapper    
    }
}

Is this the way to go in Java, or is there any other best practice for this situation?

+2  A: 

First and foremost: java methods should start lowercase. It's not enforced by the compiler or language spec, but it's a convention that everyone follows, and you'll get into trouble with tools, IDE's, and most importantly other programmers, if you don't follow it.

Wouter Lievens
Thanks for the hint, fixed that.
Space_C0wb0y
+1 because your are right -1 because its not an answer to the question and should be a comment :P
ZeissS
Right, it should have been a commentSpace Cowboy: same goes for local variables!
Wouter Lievens
A: 

Java already has standard interfaces for database abstraction called JDBC. The best practice would be to use the existing standard interfaces. Here is a good JDBC tutorial. You should get a SQLite JDBC driver and use that. SQLite.org has a comprehensive list of database drivers including JDBC drivers. Also, here is a tutorial on connecting to a SQLite database using JDBC.

Asaph
This class does use a JDBC driver. It's main purpose is to provide convenience functions for writing data to the database.
Space_C0wb0y
What do you need to add to the interface that isn't already in JDBC?
Asaph
Recognize that by adding a class that accepts a `File` object in the constructor, you've boxed yourself into using only databases that are based on a file on the local system. Most database are *not*. Why not stick to pure JDBC which will facilitate a move to another RDBMS if your application outgrows SQLite?
Asaph
What to add: The mapping from objects to database tables is non-trivial. This class handles that. Why code specifically for SQLite? Because it behaves differently than other DBMS in many cases.
Space_C0wb0y
Hove you looked at ORM tools like Hibernate?
Asaph
While inventing your own ORM is an excellent learning experience (I've done it several times) and will help you understand existing tools, it's not advised for a production project. Make sure you weigh the choices well!
Wouter Lievens
A: 

You could do

public SQLiteDatabaseWrapper(File pathToDB, boolean createNew)
        throws IOException {

    if (!pathToDB.exists()) {
        if (createNew) {
            // Create new database, potentially throws exception
        } else {
            throw new FileNotFoundException();
        }
    }

    // Open connection and setup wrapper
}

public SQLiteDatabaseWrapper(File pathToDB) throws IOException {
    this(pathToDB, false);
}

to avoid relying on static methods for creating an instance of your database wrapper.

Toon Van Acker
I usually do not like `boolean` parameters of this kind. I prefer to have two separate methods for each possible scenario. This reads better.
Space_C0wb0y
Then you've answered your own question. Your static methods are the only reasonable way to have two seperate methods for constructing an object from the same sort of parameters (`File` in this case).
Toon Van Acker