classes without a constructor
Some classes don't have constructors. I understand that all classes will inherit a default constructor, but some classes don't appear to be objects at all. Classes that have main methods in particular seem to be intended not to define objects but instead simply to instantiate other objects and to execute code...... I'm going through a tutorial that has a plethora of example classes that fit this description, but when I create new classes in Netbeans they always provide me with a costructor shell and never provide me with a main method - why is this? is there a name for the type of class I'm describing? And how do you add this type of class to an existing project in Netbeans? I know that I can add main methods and delete constructors from the classes that I create in Netbeans, that's not the point of my question.
[835 byte] By [
thousea] at [2007-11-27 10:27:42]
Yours is a good question, and unfortunately one that I can't answer except that I don't have this problem in Eclipse. It would be very poor design if the IDE forced you to do things only one way.
When you attempt to create a new main class in NetBeans, select the "Java Main Class" option.
~
I'm not a huge fan of IDE's in general. Right now I'm using both Eclipse and Netbeans - I appreciate that Eclipse prompts me to include a main method in my classes, but I don't really care too much that Netbeans doesn't. I'm really just wondering about the concept and whether or not there is a name for this type of class.
>but when I create new classes in Netbeans they always provide me with a costructor shell >and never provide me with a main method - why is this?
when creating a file create new java main class which has a main and a constructor because if you only create new java class it has no main and only constructor.
> I'm really just wondering about the concept and whether or not there is a name for this type of class.
No, there's no official name for it. Some folks call it a "main class", but a class with a public, static, void method named "main" that takes a String[] as its sole argument is just a class like any other. The only thing special about it is that the JVM will accept such a class to start a Java application.
~
I just started up Netbeans, and even when choosing a new main class, it created a default parameterless constructor. One could delete this constructor without penalty of course, but still without my desiring it, it's there.
I have another beef about netbeans as a platform for console apps, but will probably save that for another thread. Maybe I'm just biased because I started doing all this in eclipse from the get-go (that was what my son was using for his computer science class).
> when creating a file create new java main class
As mentioned in reply #2.
~
maybe I want to create a class that doesn't define an object - maybe I don't want programmers to be able to instantiate an object from it. Isn't there a way in Java to create code outside of a class altogether. I started programming with an old version of Borland C++ where object orientation was an option not a requirement - it seems as though this isn't the case in Java.
> maybe I want to create a class that doesn't define an
> object - maybe I don't want programmers to be able to
> instantiate an object from it. Isn't there a way in
> Java to create code outside of a class altogether. I
> started programming with an old version of Borland
> C++ where object orientation was an option not a
> requirement - it seems as though this isn't the case
> in Java.
Java's philosphy is different from C++, no doubt about it. And that's part of its beauty and even some of its limitations. Again, it is nothing more than a tool that is quite useful in many situations, but of course not all. I tried learning C++ years ago but found it too daunting. I have found java much more, hm shall we say "inviting". No perhaps approachable is a better term.
[ed: gads, on re-read it sounds as if I'm talking about a woman,... and one with somewhat loose morals at that!]
Message was edited by:
petes1234
> maybe I want to create a class that doesn't define an
> object - maybe I don't want programmers to be able to
> instantiate an object from it.
Declare at least one private constructor. Don't declare any non-private constructors.
Example:public class Foo {
// prevent instantiation
private Foo() { }
public static void main(String[] args) {
// code here.
}
}
> Isn't there a way in Java to create code outside of a class altogether.
No.
> I started programming with an old version of Borland
> C++ where object orientation was an option not a
> requirement - it seems as though this isn't the case
> in Java.
That's correct.
~
sounds like your heading into singleton territory. I'm just now learning about patterns and the GOF.
Message was edited by:
petes1234
Ok well I'll just have to get comfortable with the fact that not all my classes are "blueprints" that define "real-life objects"
Thanks for the answers.
> sounds like your heading into singleton territory.
Moi? Non! Per the OP, he's looking to prevent instantiation. I read that to mean not a single instance, which the code example demonstrates. For it to be a Singleton, other considerations are necessary.
~
> I'm just now learning about patterns and the GOF.
Excellent! I would also recommend Head First Design Patterns for an entry-level look at many of the GoF patterns applied to working Java examples.
~
> sounds like your heading into singleton territory.
is that a user?
> is that a user?
No; it's a design pattern that ensures (or at least attempts to ensure) that only one instance of a given class exists.
http://en.wikipedia.org/wiki/Singleton_pattern
~
> Moi? Non! Per the OP, he's looking to prevent
> instantiation. I read that to mean not a single
> instance, which the code example demonstrates.
> For it to be a Singleton, other considerations are
> necessary.
Agree. that's why the word "heading". But I do find the singleton and most all of the design patterns a "totally blow your mind" concept. I love them.
> But I do find the singleton and most all of the design patterns a
> "totally blow your mind" concept. I love them.
Word of caution: when first learning about patterns, it's easy to fall into the habit of having a solution in search of a problem (I think duffymo calls it "small boy with a pattern syndrome"). I'm not suggesting that *will* happen to you, of course. Just that it's easy to get carried away thinking one must apply all the patterns one can to any given application. :o)
~
I've got the book. Where the GOF is way too dry, this book is way too chatty and whacky. I want one that's somewhat in the middle.....
You may want to try this one (it's on my bookshelf, so I'm at least not pulling it out of thin air):
http://www.industriallogic.com/xp/refactoring/
~
> You may want to try this one (it's on my bookshelf,
> so I'm at least not pulling it out of thin air):
>
> http://www.industriallogic.com/xp/refactoring/
>
Ah,... but how much has it been openned? (kidding!).
Thanks for the recomendation! /Pete
Opened?
Text books are used as doorstops, aren't they?
> Some classes don't have constructors. I understand
> that all classes will inherit a default constructor,
No. Constructors are not inherited.
jverda at 2007-7-28 17:47:21 >
> No. Constructors are not inherited.
This is From Sun's Java Tutorial:
The compiler automatically provides a no-argument, default constructor for any class without constructors. This default constructor will call the no-argument constructor of the superclass. In this situation, the compiler will complain if the superclass doesn't have a no-argument constructor so you must verify that it does. If your class has no explicit superclass, then it has an implicit superclass of Object, which does have a no-argument constructor.
so a class will look to it's parent classes for a constructor to use? This sounds an awful lot like inheritance to me.
> > No. Constructors are not inherited.
>
> This is From Sun's Java Tutorial:
>
> The compiler automatically provides a no-argument,
> default constructor for any class without
> constructors. This default constructor will call the
> no-argument constructor of the superclass. In this
> situation, the compiler will complain if the
> superclass doesn't have a no-argument constructor so
> you must verify that it does. If your class has no
> explicit superclass, then it has an implicit
> superclass of Object, which does have a no-argument
> constructor.
>
>
> so a class will look to it's parent classes for a
> constructor to use? This sounds an awful lot like
> inheritance to me.
Not in the least. If it inherited it, you wouldn't have to explicitly write a constructor in the subclass. Which you do
> Not in the least. If it inherited it, you wouldn't
> have to explicitly write a constructor in the
> subclass. Which you do
"The compiler automatically provides a no-argument, default constructor for any class without constructors"
> The compiler automatically provides a no-argument
The fact that the compiler has to provide a constructor is in no way an example of inheritance, it clearly shows that the constructor is not inherited.
Assuming constructors would be inherited, here is an example :public class A {
public A(int value) {
}
}
public class B extends A {
}
If A's constructor was inherited, then B should compile fine. Moreover, it should be possible to doB b = new B(0);
But what happens is that the compiler consider B having a default no-arg constructor (because it defines none), basically :public class B extends A {
public B() {
super();
}
}
The compiler then complains about the fact that A doesn't define a no-arg constructor.
And the A(int) constructor is still not inherited by B.
> > Not in the least. If it inherited it, you wouldn't
> > have to explicitly write a constructor in the
> > subclass. Which you do
>
> "The compiler automatically provides a no-argument,
> default constructor for any class without
> constructors"
Ok, you win. The JLS is wrong and constructors are inherited, yet still have to be provided explicitly. Congratulations
> > Not in the least. If it inherited it, you wouldn't
> > have to explicitly write a constructor in the
> > subclass. Which you do
>
> "The compiler automatically provides a no-argument,
> default constructor for any class without
> constructors"
That doesn't have anything to do with inheritance.
class SuperClass
{
public SuperClass(int num)
{
System.out.println(num);
}
}
class SubClass extends SuperClass { }
Tell us what happens when you call:
SubClass sc = new SubClass(5);
Edit: Tim's reply definitely wasn't there when I started replying...
I use the IDE "JCreator" it's pretty clean and doesn't interfere too much with coding style. Using the console is harder than say "Eclipse" but I still think it does the job.
You don't need constructors in classes but in some cases prove useful.
>
> Ok, you win. The JLS is wrong and constructors are
> inherited, yet still have to be provided explicitly.
> Congratulations
George - you're not helpful... I'm just asking a question. If you're not trying to answer it then why bother posting anything?
> >
> > Ok, you win. The JLS is wrong and constructors are
> > inherited, yet still have to be provided
> explicitly.
> > Congratulations
>
> George - you're not helpful... I'm just asking a
> question. If you're not trying to answer it then why
> bother posting anything?
You said: "so a class will look to it's parent classes for a constructor to use? This sounds an awful lot like inheritance to me."
Not so much a question, as you implying that the (correct) information you had been given was wrong. Given that people who do that generally refuse to accept that they have made a mistake - at least not until the thread has degenerated into a mess of arguing for page after page - I thought I'd just let you think you were right up-front and save everybody else a flame war
I didn't bother answering your question because you'd already shown willing to disagree with answers straight from the JLS anyway. You disagreed with the JLS, and argued against my point as well, so I had no reason to believe you would accept any subsequent proof as a fact. I wasn't about to try and persuade you otherwise given your steadfast refusal to believe me before
>
> I didn't bother answering your question because .......
don't bother to answer any of my questions
> >
> > I didn't bother answering your question because
> .......
>
> don't bother to answer any of my questions
I won't. Nice attitude, by the way. So very typical these days, sadly. What an idiot
"wah! wah! I'm right and you're all wrong! wah! wah!" - seen it all before. Next
> > >
> > > I didn't bother answering your question because
> > .......
> >
> > don't bother to answer any of my questions
>
> I won't. Nice attitude, by the way. So very typical
> these days, sadly. What an idiot
>
> "wah! wah! I'm right and you're all wrong! wah! wah!"
> - seen it all before. Next
Have a nice day George.....
> You said: "so a class will look to it's parent
> classes for a constructor to use? This sounds an
> awful lot like inheritance to me."
Honestly, I took that as a question. A statement doesn't have to have a question mark for it to be interpreted as a question.
> > You said: "so a class will look to it's parent
> > classes for a constructor to use? This sounds an
> > awful lot like inheritance to me."
>
> Honestly, I took that as a question. A statement
> doesn't have to have a question mark for it to be
> interpreted as a question.
Either way, he's saying "I don't believe what the JLS says and what other posters have told me to be true". No point trying to change his mind, given that that almost always leads to a flame war
> Either way, he's saying "I don't believe what the JLS
> says and what other posters have told me to be true".
> No point trying to change his mind, given that that
> almost always leads to a flame war
Nobody had mentioned the JLS at that point, so why would you assume that I'd be saying I don't believe the JLS?
Plus - can't I question responses? Is every response on this site exactly right and able to be taken without question?
> > Either way, he's saying "I don't believe what the
> JLS
> > says and what other posters have told me to be
> true".
> > No point trying to change his mind, given that
> that
> > almost always leads to a flame war
>
> Nobody had mentioned the JLS at that point, so why
> would you assume that I'd be saying I don't believe
> the JLS?
>
> Plus - can't I question responses? Is every response
> on this site exactly right and able to be taken
> without question?
Not in the least. Of course you can question responses. I found the tone of the challenge to be scornful. "But isn't that inheritance?" would suggest you didn't understand, or wanted clarification, but "this sounds an awful lot like inheritance to me" is rhetorical, as if that is what you believe and it should be obvious to anyone else that this is the case. Hence my dismissive response. Maybe you're just an innocent victim of the ever-increasing amount of people coming here who absolutely will not accept being disagreed with, I don't know. If that's the case, I'm sorry I misconstrued your response
> so a class will look to it's parent classes for a
> constructor to use?
A class' constructor will call its parent's no-arg constructor if no explicit super(...) call is provided. That's not inheritance. Inheritance would be if the child class had the same c'tors available as its parent without them being expclicitly defined, simply by virtue of the fact that the c'tor is present in the parent.
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.8
JLS 8.8 Constructor Declarations
Constructor declarations are not members. They are never inherited and therefore are not subject to hiding or overriding.
jverda at 2007-7-28 17:47:26 >
> but some classes don't appear to be objects at all. Classes that have main methods in particular seem to be intended not to define objects but instead simply to instantiate other objects and to execute code...
> is there a name for the type of class I'm describing?
to me it sounds like the OP just wants to learn about the 'static' keyword.
> > but some classes don't appear to be objects at
> all. Classes that have main methods in particular
> seem to be intended not to define objects but instead
> simply to instantiate other objects and to execute
> code...
> > is there a name for the type of class I'm
> describing?
>
> to me it sounds like the OP just wants to learn about
> the 'static' keyword.
Hmmmm. One can write a class which has no static members, but which when instantiated, doesn't actually produce an object. Sure, it will be an instance of java.lang.Object, but that alone isn't (in the strict sense of the word) an object. A true object has both data and behaviour, so
public class NotReallyAnObject {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
while a subclass of java.lang.Object, isn't really an object, since it defines no behaviours. All subject to debate and differences of opinion, of course
nothing to see here. no double posts. move along please
Message was edited by:
georgemc
> to me it sounds like the OP just wants to learn about
> the 'static' keyword.
OP?
> > to me it sounds like the OP just wants to learn
> about
> > the 'static' keyword.
>
> OP?
Original Poster - you
> > OP?
>
> Original Poster - you
And in some contexts (not this one), it's the Original Post; i.e., the first post in the thread.
~
