Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #37276
| From | Andreas Leitgeb <avl@logic.at> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Using main from abstract class in concrete class |
| Date | 2017-08-18 19:48 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <slrnopehbp.o2q.avl@logic.at> (permalink) |
| 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> |
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.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Using main from abstract class in concrete class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 11:47 +0200
Re: Using main from abstract class in concrete class Andreas Leitgeb <avl@logic.at> - 2017-08-13 10:59 +0000
Re: Using main from abstract class in concrete class Andreas Leitgeb <avl@logic.at> - 2017-08-13 11:38 +0000
Re: Using main from abstract class in concrete class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 15:43 +0200
Re: Using main from abstract class in concrete class Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-08-13 10:32 -0400
Re: Using main from abstract class in concrete class Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-08-13 10:37 -0400
Re: Using main from abstract class in concrete class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 17:17 +0200
Re: Using main from abstract class in concrete class Andreas Leitgeb <avl@logic.at> - 2017-08-17 18:56 +0000
Re: Using main from abstract class in concrete class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-18 06:37 +0200
Re: Using main from abstract class in concrete class Andreas Leitgeb <avl@logic.at> - 2017-08-18 19:48 +0000
Re: Using main from abstract class in concrete class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-18 23:37 +0200
Re: Using main from abstract class in concrete class Cecil Westerhof <Cecil@decebal.nl> - 2017-08-19 01:32 +0200
Re: Using main from abstract class in concrete class Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2017-08-13 12:03 -0500
csiph-web