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: Sat, 19 Aug 2017 01:32:49 +0200
Organization: Decebal Computing
Lines: 76
Message-ID: <87fucoih9a.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> <87k220iml8.fsf@munus.decebal.nl>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="3820b20d39a2e7728f71dbc5da182e9b"; logging-data="11453"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/feYdvJUwhaY2ZWxy7aXPks9/Qdc+XGc8="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
X-Homepage: http://www.decebal.nl/
Cancel-Lock: sha1:MfGAx0r9GlJTwQBdjCTigICP58E= sha1:e/yqzX98YM8bNfnjQkFrw2NKl1Q=
Xref: csiph.com comp.lang.java.programmer:37279

Cecil Westerhof <Cecil@decebal.nl> writes:

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

It has become:
	public static void main(final String[] args) throws SQLException {
		MainWorkParams params = checkArgs(args);

		try (SQLite3 sqlite3 = new SQLite3(
				params.database,
				params.user,
				params.password)) {
			sqlite3.mainWork(params.action, params.restArgs);
		}
	}


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

Done.

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