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 23:37:39 +0200
Organization: Decebal Computing
Lines: 69
Message-ID: <87k220iml8.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> <87valljxtp.fsf@munus.decebal.nl> <slrnopehbp.o2q.avl@logic.at>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="4e79c97da8fb74945529c91ed76be274"; logging-data="22582"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19sqOC+Nj4txN6mbscFqTow95bg+HB1QzA="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
X-Homepage: http://www.decebal.nl/
Cancel-Lock: sha1:9zrcAJlw6e3yfqECR+X64uhmh8I= sha1:LNA8OllnS8idO7gTl/OILcmbmt0=
Xref: csiph.com comp.lang.java.programmer:37278

Andreas Leitgeb <avl@logic.at> writes:

> Cecil Westerhof <Cecil@decebal.nl> wrote:
>> 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()
>>
>> The idea is that mainWork is always called from the main of a class.
>
> Yes, that was already pretty clear from your example snippet.
>
> But even a static method of a subclass *can* create an instance of
> its own class (and also of any other accessible class):
>
>   public class SQLite3 extends SQL {
>       // ################ main
>       public static void main(final String[] args) throws SQLException {
>           SQL.mainWork(new SQLite3(), args);
>       }
>
> and SQL.mainWork would be declared as taking (SQL sqlSubInstance,
> String[] args)

There is some checking done in mainWork. But I could put that in a
separate function and call this from the main and return this to the
main. It makes the mains a little bigger, but removes not that clear
code from mainWork.
Something to implement.


> If you expect that your abstract class will need to create more
> instances of the relevant subclass, then using the factory pattern
> might be preferable to repeated .forName'ing.

At the moment that does not seem very likely. The main function is
only for some simple functions. For example I use it with SQLite to
check the lock status of databases.


>>> 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.
>>
>> Is there a good reason to want derived classes in another package?
>
> In some earlier posts you expressed your intention to make your class
> also usable for others.
>
> If someone else wanted to derive from your abstract SQL class, they
> probably wouldn't want to put their derived class in a package starting
> with nl.decebal., but probably rather in a package reflecting their
> own domain.

That is a good point. I will change it.

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