Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37152 > unrolled thread

Is this a correct implementation of an abstract class and implementation class

Back to article view | Back to comp.lang.java.programmer

Contents

  Is this a correct implementation of an abstract class and implementation class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-12 23:20 +0200
    Re: Is this a correct implementation of an abstract class and implementation class Arne Vajhøj <arne@vajhoej.dk> - 2017-08-12 22:00 -0400
      Re: Is this a correct implementation of an abstract class and implementation class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 07:14 +0200
      Re: Is this a correct implementation of an abstract class and implementation class Andreas Leitgeb <avl@logic.at> - 2017-08-13 09:37 +0000
        Re: Is this a correct implementation of an abstract class and implementation class Andreas Leitgeb <avl@logic.at> - 2017-08-13 10:13 +0000
          Re: Is this a correct implementation of an abstract class and implementation class Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:27 -0400
        Re: Is this a correct implementation of an abstract class and implementation class lewbloch@gmail.com - 2017-08-13 09:49 -0700
        Re: Is this a correct implementation of an abstract class and implementation class Arne Vajhøj <arne@vajhoej.dk> - 2017-08-13 16:25 -0400
    Re: Is this a correct implementation of an abstract class and implementation class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 07:33 +0200

#37152 — Is this a correct implementation of an abstract class and implementation class

I want to write a layer around JDBC. For this I have an abstract class
SQL in which I have the following constructor and abstract methods:
    // ################ constructors
    public SQL (String database) throws SQLException {
        String forName   = getForName();
        String sqlDriver = getSQLDriver();

        try {
            Class.forName(forName);
        } catch (ClassNotFoundException e) {
            throw new SQLException("Could not find the class " + forName + ".");
        }
        conn = DriverManager.getConnection(sqlDriver + database);
        this.database = database;
    }

    // ################ abstract
    abstract String getForName();
    abstract String getSQLDriver();


I have also an implementation class SQLite3 in which I have:
    // ################ constructors
    public SQLite3 (String database) throws SQLException {
        super(database);
    }

    // ################ default
    @Override
    String getForName() {
        return "org.sqlite.JDBC";
    }

    @Override
    String getSQLDriver() {
        return "jdbc:sqlite:";
    }

Is this the correct way to do this, or is there a better way?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#37159

On 8/12/2017 5:20 PM, Cecil Westerhof wrote:
> I want to write a layer around JDBC. For this I have an abstract class
> SQL in which I have the following constructor and abstract methods:
>      // ################ constructors
>      public SQL (String database) throws SQLException {
>          String forName   = getForName();
>          String sqlDriver = getSQLDriver();
> 
>          try {
>              Class.forName(forName);
>          } catch (ClassNotFoundException e) {
>              throw new SQLException("Could not find the class " + forName + ".");
>          }
>          conn = DriverManager.getConnection(sqlDriver + database);
>          this.database = database;
>      }
> 
>      // ################ abstract
>      abstract String getForName();
>      abstract String getSQLDriver();
> 
> 
> I have also an implementation class SQLite3 in which I have:
>      // ################ constructors
>      public SQLite3 (String database) throws SQLException {
>          super(database);
>      }
> 
>      // ################ default
>      @Override
>      String getForName() {
>          return "org.sqlite.JDBC";
>      }
> 
>      @Override
>      String getSQLDriver() {
>          return "jdbc:sqlite:";
>      }
> 
> Is this the correct way to do this, or is there a better way?

I have done something similar many times.

I like the approach.

:-)

I assume you are aware that with newer Java versions then
Class.forName is not required.

And I would rename getSQLDriver to getURLPrefix.

Arne

[toc] | [prev] | [next] | [standalone]

#37160

Arne Vajhøj <arne@vajhoej.dk> writes:

> On 8/12/2017 5:20 PM, Cecil Westerhof wrote:
>> I want to write a layer around JDBC. For this I have an abstract class
>> SQL in which I have the following constructor and abstract methods:
>>      // ################ constructors
>>      public SQL (String database) throws SQLException {
>>          String forName   = getForName();
>>          String sqlDriver = getSQLDriver();
>>
>>          try {
>>              Class.forName(forName);
>>          } catch (ClassNotFoundException e) {
>>              throw new SQLException("Could not find the class " + forName + ".");
>>          }
>>          conn = DriverManager.getConnection(sqlDriver + database);
>>          this.database = database;
>>      }
>>
>>      // ################ abstract
>>      abstract String getForName();
>>      abstract String getSQLDriver();
>>
>>
>> I have also an implementation class SQLite3 in which I have:
>>      // ################ constructors
>>      public SQLite3 (String database) throws SQLException {
>>          super(database);
>>      }
>>
>>      // ################ default
>>      @Override
>>      String getForName() {
>>          return "org.sqlite.JDBC";
>>      }
>>
>>      @Override
>>      String getSQLDriver() {
>>          return "jdbc:sqlite:";
>>      }
>>
>> Is this the correct way to do this, or is there a better way?
>
> I have done something similar many times.
>
> I like the approach.

Thank you.


> I assume you are aware that with newer Java versions then
> Class.forName is not required.

Not, I was not. I removed it.


> And I would rename getSQLDriver to getURLPrefix.

Good tip: done.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37166

Arne Vajhøj <arne@vajhoej.dk> wrote:
> I assume you are aware that with newer Java versions then
> Class.forName is not required.

I googled for "jdbc" and "forName", hoping that I'd find some with
a negative context for "forName", but these still seem to be too
well hidden (like e.g. on second result page)...

Any hint for some more more successful google-terms for the
new feature?

I only remember, when having to call "registerDriver" finally
came out of fashion - in favour of just "forName"ing the driver
class.

[toc] | [prev] | [next] | [standalone]

#37171

Andreas Leitgeb <avl@logic.at> wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I assume you are aware that with newer Java versions then
>> Class.forName is not required.
> I googled for "jdbc" and "forName", hoping that I'd find some with
> a negative context for "forName", but these still seem to be too
> well hidden...

Well, found it, afterall, but I'm not overly impressed.
iiuc, then instead of providing the driver class name and
the dbURI for an app, I'd instead provide the dbURI to
the app, and need to provide the used drivername(s) already
to the JVM.

Not saying that there couldn't be cases where this would be
advantageous, I just can't think of one right now.

[toc] | [prev] | [next] | [standalone]

#37196

On 8/13/2017 6:13 AM, Andreas Leitgeb wrote:
> Andreas Leitgeb <avl@logic.at> wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> I assume you are aware that with newer Java versions then
>>> Class.forName is not required.
>> I googled for "jdbc" and "forName", hoping that I'd find some with
>> a negative context for "forName", but these still seem to be too
>> well hidden...
>
> Well, found it, afterall, but I'm not overly impressed.
> iiuc, then instead of providing the driver class name and
> the dbURI for an app, I'd instead provide the dbURI to
> the app, and need to provide the used drivername(s) already
> to the JVM.

????

Before:

Class.forName
DriverManager.getConnection

After:

DriverManager.getConnection

 From 2 lines to 1 line.

There are corner cases with drivers not supporting service model,
having two drivers for the same URL etc., but in 99% of cases you
just drop the Class.forName and it works.

Arne

[toc] | [prev] | [next] | [standalone]

#37184

http://docs.oracle.com/javase/tutorial/jdbc/basics/connecting.html
_et seq._

[toc] | [prev] | [next] | [standalone]

#37195

On 8/13/2017 5:37 AM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I assume you are aware that with newer Java versions then
>> Class.forName is not required.
>
> I googled for "jdbc" and "forName", hoping that I'd find some with
> a negative context for "forName", but these still seem to be too
> well hidden (like e.g. on second result page)...
>
> Any hint for some more more successful google-terms for the
> new feature?

It is a "new" feature in Java 1.6.

Not sure about the Google term, but:

https://docs.oracle.com/javase/6/docs/api/java/sql/DriverManager.html

<quote>
The DriverManager methods getConnection and getDrivers have been 
enhanced to support the Java Standard Edition Service Provider 
mechanism. JDBC 4.0 Drivers must include the file 
META-INF/services/java.sql.Driver. This file contains the name of the 
JDBC drivers implementation of java.sql.Driver. For example, to load the 
my.sql.Driver class, the META-INF/services/java.sql.Driver file would 
contain the entry:

  my.sql.Driver


Applications no longer need to explictly load JDBC drivers using 
Class.forName(). Existing programs which currently load JDBC drivers 
using Class.forName() will continue to work without modification. </quote>

Arne

[toc] | [prev] | [next] | [standalone]

#37161

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Cecil Westerhof <Cecil@decebal.nl> writes:
>>public SQLite3 (String database) throws SQLException {
>>    super(database);
>>}
>>Is this the correct way to do this, or is there a better way?
>
>   There is no »correct« in this case. There are different
>   possibilities. But the choice between them depends on the
>   use expected, and you know best how you expect the classes
>   to be used.

In a way I do not. ;-) I am writing it as an exercise and to make live
a little easier for myself. But I am thinking about sharing it, so it
can be used in a lot of ways.

For example: I will ‘always’ use the database connection for the whole
run of my program, but I made the class AutoCloseable, so it can also
be used in a try with resources, even if I do not use it that way.


>   You are using the Template Method pattern to provide
>   arguments to an abstract superclass, but you just fill in
>   string values, not operations with behavior, so you could
>   have a single class that takes the database, the package and
>   the driver path as arguments as well. Or, if you want to
>   factor out the package and driver:

At the moment I only implemented SQLite3. But this has the methods:
    getSQLiteVersion
    isDBLocked

And the fields:
    GET_SQLITE_VERS
    SQLITE_BUSY
    UNEXPECTED_ERROR

Also I do not want have to give the driver path.

So for the moment I stick with what I have got.


I probably should rename getSQLiteVersion to getDBVersion, because
probably other drivers will have the same functionality.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web