Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Cecil Westerhof <Cecil@decebal.nl>
Newsgroups: comp.lang.java.programmer
Subject: Re: Using main from abstract class in concrete class
Date: Fri, 18 Aug 2017 06:37:22 +0200
Organization: Decebal Computing
Lines: 57
Message-ID: <87valljxtp.fsf@munus.decebal.nl>
References: <87h8xbx0ig.fsf@munus.decebal.nl> <ompnlf$7j6$1@dont-email.me> <87wp67v6of.fsf@munus.decebal.nl> <slrnopbpu1.o2q.avl@logic.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="4e79c97da8fb74945529c91ed76be274"; logging-data="1664"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19LX99NIEQNACPDqeX5xImGfwiusTmkPfQ="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:Ju2hlT+t2pslLBXyGOS1q5NYkIE= sha1:gMLOFYf8M9J++7MeDKvp8YZiAgo=
X-Homepage: http://www.decebal.nl/
Xref: csiph.com comp.lang.java.programmer:37268

Andreas Leitgeb <avl@logic.at> writes:

> Cecil Westerhof <Cecil@decebal.nl> wrote:
>> I do something like that now:
>>     public class SQLite3 extends SQL {
>>         // ################ main
>>         public static void main(final String[] args) throws SQLException {
>>             SQL.mainWork(SQLite3.class.getCanonicalName(), args);
>>         }
>
> Why not change "mainWork" such, that it accepts a Class ref directly,
> rather than the canonical name?
>
> Maybe even simpler would be to have it accept a SQL ref and just pass
> it: new SQLite3()
>
> There is certainly more than one way to Rome.

The idea is that mainWork is always called from the main of a class.
But I can always ponder about this possibility.
Also I probably make AbstractSQL a concrete class named SQLWrapper.


>> I renamed main in the abstract class SQL to mainWork and removed
>> public.
>
> You might want to add "protected", so that derived classes even in
> other packages can still call it.  "protected" is more permissive than 
> default access.

It is something to think about. Is there a good reason to want derived
classes in another package?


I am thinking about changing AbstractSQL to SQLWrapper (and removing
abstract) and letting SQLWrapper be called with a URLPrefix, so it can
be used for databases where there is no concrete class for yet.


There are databases that can use in memory databases. For example
sqlite3 uses :memory:. I first had testDB.sqlite as database to test.
I am thinking about changing it to :memory:. Is that good enough, or
should I always check also for a stored database?

For sqlite3 I need to use (also) a ‘real’ database anyway, because I
need to check the lock functionality.


I have unit tests to test AbstractSQL, SQLResultSet and SQLStatement
(the classes I so far defined). I test those classes with the SQLite3
class. Is that good enough, or should they be tested with every
concrete class?

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