Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Andreas Leitgeb <avl@logic.at>
Newsgroups: comp.lang.java.programmer
Subject: Re: Using main from abstract class in concrete class
Date: Fri, 18 Aug 2017 19:48:10 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <slrnopehbp.o2q.avl@logic.at>
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>
Reply-To: avl@logic.at
Injection-Date: Fri, 18 Aug 2017 19:48:10 -0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="67f969917c129fb31f6473b3996c788f"; logging-data="26194"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+OvLoDkf17b8765yjhKm67"
User-Agent: slrn/1.0.2 (Linux)
Cancel-Lock: sha1:OtcShsHf3+B4yeJfgvjLPQPHbMc=
Xref: csiph.com comp.lang.java.programmer:37276

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)

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.


>> 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.