Inheritance and lousy Frame

[NickName]

Hi,

First of all, I'm a java newbie.
I'm exploring the Java's Inheritance feature. The guiding doc is a
piece from Borland, seems not bad, the IDE is JBuilder 2005. A super
class is called MammalClass and two subclasses are named DogClass and
ManClass respectively, conceptually I don't seem to have any problem
writing some Accessor methods for the super class and then
call/reference them from the two subclasses, however, to demo how they
works, one needs some sort of interface like a frame or window to
display each subclass's properties, and I find the Frame, JFrame and
JPanel etc. very annoying in the sense that JBuilder provides some GUI
to use them and yet, the fields for each subclass do not appear right,
so, I did not even run the code. Any alternative to Frame? What would
it take to use Web form? Or ???? to let me test them out.

TIA.

 

[Andrew Thompson]

Hi,

First of all, I'm a java newbie.

OK.. so I'll explain (calmly) that the title
"Inheritance and lousy Frame" - in slagging
the language or tool set you are using,
hardly encourages people to answer you
seriously, or politely.

Andrew T.

 

[Oliver Wong]

Hi,

First of all, I'm a java newbie.
I'm exploring the Java's Inheritance feature. The guiding doc is a
piece from Borland, seems not bad, the IDE is JBuilder 2005. A super
class is called MammalClass and two subclasses are named DogClass and
ManClass respectively, conceptually I don't seem to have any problem
writing some Accessor methods for the super class and then
call/reference them from the two subclasses, however, to demo how they
works, one needs some sort of interface like a frame or window to
display each subclass's properties, and I find the Frame, JFrame and
JPanel etc. very annoying in the sense that JBuilder provides some GUI
to use them and yet, the fields for each subclass do not appear right,
so, I did not even run the code. Any alternative to Frame? What would
it take to use Web form? Or ???? to let me test them out.

If the issue is the IDE, use a different one, or learn to compile from
the command line.

The main alternative to Frame is JFrame. You could try changing your
application into an Applet (or JApplet), but this will probably end up
making your life harder. Depending on what your application does, you can
change it from being a GUI application to a console based one, and use
System.out.println() instead.

Using a web form would probably require you to set up a webserver, and
have some way to invoke Java. One way would be to use an application server
and JSP. Another way would be to use CGI. If this sounds like it's way over
your head, then I recommend you don't take the "web form" route.

If you just want to test out some theories about inheritance, I
recommend using System.out.println.

- Oliver

 

[Ian Wilson]

I'm exploring the Java's Inheritance feature.

Then I'd start by exploring that in isolation from other complicated
Java features.

to demo how they
works, one needs some sort of interface like a frame or window to
display each subclass's properties, and I find the Frame, JFrame and
JPanel etc. very annoying in the sense that JBuilder provides some GUI
to use them and yet, the fields for each subclass do not appear right,
so, I did not even run the code.

Place your exploratory code within a Java console application and use
System.out.println() to display your results. Add a toString() method to
your Classes to facilitate this.

When you have explored inheritance sufficiently, then move on to
exploration of other Java concepts. Do GUI apps later. Don't try to do
too many new things at once.

-----------------------------------------------
class ExploreInheritance {

public static void main(String[] args) {
Dog fido = new Dog();
System.out.println(fido);
}

class Mammal {
int legs = 0;
Mammal(int legs) {
this.legs = legs;
}
public String toString() {
return "A mammal with "+legs+" legs";
}
}

class Dog extends Mammal {
Dog() {
super(4);
}
}
}

 

[NickName]

I'm exploring the Java's Inheritance feature.

Then I'd start by exploring that in isolation from other complicated
Java features.

to demo how they
works, one needs some sort of interface like a frame or window to
display each subclass's properties, and I find the Frame, JFrame and
JPanel etc. very annoying in the sense that JBuilder provides some GUI
to use them and yet, the fields for each subclass do not appear right,
so, I did not even run the code.

Place your exploratory code within a Java console application and use
System.out.println() to display your results. Add a toString() method to
your Classes to facilitate this.

When you have explored inheritance sufficiently, then move on to
exploration of other Java concepts. Do GUI apps later. Don't try to do
too many new things at once.

-----------------------------------------------
class ExploreInheritance {

public static void main(String[] args) {
Dog fido = new Dog();
System.out.println(fido);
}

class Mammal {
int legs = 0;
Mammal(int legs) {
this.legs = legs;
}
public String toString() {
return "A mammal with "+legs+" legs";
}
}

class Dog extends Mammal {
Dog() {
super(4);
}
}
}

First let me thank you and every one else who responded to my question.
Now, the exact code above generated "non-static variable this cannot
be referenced from a static context ..."
err msg. But being a "genius" myself I fix it , ok, earnestly, with
a little research, I added the key word prefix, "static" to the two
classes, then the code are in "snyc" and works.
(This part is unintended gain

And yes, the idea of ingoring other features first while learning
Inheritance is a sound one.

Once again, many thanks.

 

[NickName]

Ok, I'm in trouble again.
Following the idea of doing one thing a time, I deleted a frame class
and left a super class and two subclasses, see respective code below
and added some System.out.println("TestOutput") lines for one of the
two subclasses, but the debug console did not output them and yet I did
not get any compilation errors. What's wrong? As usual, many thanks.
IDE in question, JBuilder 2005.

Would it have anything to do with abstract class? It does not seem to
be the case, I commented them out, still no show.

// super class
// goal: define some attributes for mammal
package oop1;

abstract public class MammalClass {
// members variable definition
private String name, eyeColor;
private int age;


public static void main(String[] args) {
};

// Accessor methods
// name property
public String getName() {
return name;
}
public void setName(String value) {
name = value;
}

// eyeColor property
public String getEyeColor() {
return eyeColor;
}
public void setEyeColor(String value) {
eyeColor = value;
}

// age property
public int getAge() {
return age;
}
public void setAge(int value) {
if (value > 0) {
age = value;
}
else {
age = 0;
}
}

// provide default value
public MammalClass() {
setName("some name");
setEyeColor("dark");
setAge(10);

System.out.println("test output from super class");
}

// abstract class, abstract method; declare at the supper class level
but implemented at each subclass
abstract public void speed();

}


// subclass
// goals:
// a) use super class to inherit some attribute from mammal;
// b) define some of its own attribute

package oop1;

public class DogClass extends MammalClass{
// class members
// boolean hasTail;
// use the parent's members as well

private boolean Tail;

public boolean hasTail() {
return Tail;
}
public void setTail(boolean value) {
Tail = value;
}

// calling super class's Accessor methods
public DogClass() {
setName("Pal");
setAge(3);

// test output
System.out.println("My dog: " + getName());
System.out.println("is + " + getAge() + "now.");
}

public void speed() {
javax.swing.JOptionPane.showMessageDialog(null, "30 mph", "Dog
Speed", 1);
}

}

 

[Lew]

package oop1;

abstract public class MammalClass {
// members variable definition
private String name, eyeColor;
private int age;


public static void main(String[] args) {
};

This declaration of a main() serves no purpose here.

// Accessor methods
// name property
public String getName() {
return name;
}
public void setName(String value) {
name = value;
}

Methods like this should be declared "final" to prevent a subclass override,
if they are to be used in a constructor.

// eyeColor property
public String getEyeColor() {
return eyeColor;
}
public void setEyeColor(String value) {
eyeColor = value;
}

// age property
public int getAge() {
return age;
}
public void setAge(int value) {
if (value > 0) {
age = value;
}
else {
age = 0;
}
}

// provide default value
public MammalClass() {
setName("some name");
setEyeColor("dark");
setAge(10);

Because if the subclass overrides these methods, you could have some pain in
the superclass constructor.

System.out.println("test output from super class");
}

// abstract class, abstract method; declare at the supper class level
but implemented at each subclass
abstract public void speed();

}


// subclass
package oop1;

public class DogClass extends MammalClass{
// class members
// boolean hasTail;
// use the parent's members as well

private boolean Tail;

Variable names should begin with a lower-case letter.

public boolean hasTail() {
return Tail;
}
public void setTail(boolean value) {
Tail = value;
}

// calling super class's Accessor methods
public DogClass() {
setName("Pal");
setAge(3);

This would actually invoke the subclass's methods if there were such
overrides. Depending on the subclass's method definitions, that could break
your code.

Putting non-final public methods in a constructor is dangerous.

// test output
System.out.println("My dog: " + getName());
System.out.println("is + " + getAge() + "now.");
}

public void speed() {
javax.swing.JOptionPane.showMessageDialog(null, "30 mph", "Dog
Speed", 1);

Not sure that suddenly throwing a Swing class into a console app is such a
good idea.

}

}

- Lew

 

[Andrew Thompson]

NickName wrote: .....

Not sure that suddenly throwing a Swing class into a console app is such a
good idea.

Why? I do it 'regularly' (the rare occasions I am
developing a CLI app. and need some input).
The only problem I can see, is that this code can
not later be used in a headless environment
(servlet, batch processing).

Andrew T.

 

[Ian Wilson]

Ok, I'm in trouble again.
Following the idea of doing one thing a time, I deleted a frame class
and left a super class and two subclasses, see respective code below
and added some System.out.println("TestOutput") lines for one of the
two subclasses, but the debug console did not output them and yet I did
not get any compilation errors. What's wrong?

public static void main(String[] args) {
};

<snip>

When you run a Java application, it runs the main() method of the
specified class. If your main method does nothing then nothing is what
happens.

Maybe between the two lines I've quoted you should instantiate an object
by inserting
DogClass rex = new DogClass();



I think "Dog" is a better classname than "DogClass". You know it is a
class because it starts with a capital letter. This is why "Tail" is a
poor name for a variable (use "tail" instead).

 

[NickName]

<snip>

When you run a Java application, it runs the main() method of the
specified class. If your main method does nothing then nothing is what
happens.

Maybe between the two lines I've quoted you should instantiate an object
by inserting
DogClass rex = new DogClass();



I think "Dog" is a better classname than "DogClass". You know it is a
class because it starts with a capital letter. This is why "Tail" is a
poor name for a variable (use "tail" instead).

Thank you all. It is working now with your help. Ok, lessions learned
for me:
a) subclass object must be instantiated from the super class;
b) methods in super class need to use final keyword to prevent override
from subclass;
c) variable name needs to start from a lower case letter.

Now, a new question arises, I'm trying to use abstract method, speed,
in this case.
Definition at the super class level,
// abstract class, abstract method; declare at the supper class level
but implemented at each subclass
abstract public void speed();

Definition at a subclass level,
public void speed() {
// javax.swing.JOptionPane.showMessageDialog(null, "30 mph", "Dog
Speed", 1);
System.out.println("30 mph");
}

Attempt to call the speed method in the Dog class (from the super
class):
public static void main(String[] args) {
Dog pet = new Dog();
System.out.println(pet.speed());
};

The above attempt failed, err msg:
"MammalClass.java": 'void' type not allowed here at line 24, column 33

Any idea what's happening? Many thanks.

 

[Ian Wilson]

Now, a new question arises,

It is usually a good idea to start a new thread for a new question
rather than adding your question to an existing discussion.

I have changed the subject to indicate the new question.

public void speed() {
System.out.println("30 mph");
}
public static void main(String[] args) {
Dog pet = new Dog();
System.out.println(pet.speed());

println() takes an argument that should be printable, usually that means
a string. Your speed() method soes not return a String value or any
other type of value that can be printed.

};

The above attempt failed, err msg:
"MammalClass.java": 'void' type not allowed here at line 24, column 33

Println cannot print nothingness.

You can fix this in one of two ways ...

1)
Change speed() to
public String speed() {
return "30 mph";
}

OR

2)
Change
System.out.println(pet.speed());
to
pet.speed();

Don't do both changes


A note on naming ...
I'd name your existing speed() as printSpeed()
I'd name the revised speed() in (1) as getSpeed()

Designwise, maybe `public int getMPH()` would be better?

 

[Patricia Shanahan]

NickName wrote:
....

Thank you all. It is working now with your help. Ok, lessions learned
for me:
a) subclass object must be instantiated from the super class;

I don't even understand this remark.

b) methods in super class need to use final keyword to prevent override
from subclass;

Unless they are designed and intended to be overridden. For example,
java.util.AbstractSet provides a series of default implementations of
methods in the Set interface. Most actual Set implementing classes
extend AbstractSet and override some of the methods.

c) variable name needs to start from a lower case letter.

It is conventional style. The compiler does not care, but human readers
who are used to reading e.g. Sun's Java code will find it easier to read
if you do stick to the conventions.

Now, a new question arises, I'm trying to use abstract method, speed,
in this case.

....

You seem to be attempting to discover the rules of the language, and how
to use it, experimentally.

Have you considered working through a book or tutorial? That would not
just explain the rules, it would explain when and how to use features.

Patricia

 

[NickName]

Now, a new question arises, [...]
};

The above attempt failed, err msg:
"MammalClass.java": 'void' type not allowed here at line 24, column 33

Println cannot print nothingness.

You can fix this in one of two ways ...

1)
Change speed() to
public String speed() {
return "30 mph";
}

OR

2)
Change
System.out.println(pet.speed());
to
pet.speed();

Don't do both changes


A note on naming ...
I'd name your existing speed() as printSpeed()
I'd name the revised speed() in (1) as getSpeed()

Designwise, maybe `public int getMPH()` would be better?

Thank you, it chose option 2, it works great.

 

[NickName]

Now, a new question arises, [...]
};

The above attempt failed, err msg:
"MammalClass.java": 'void' type not allowed here at line 24, column 33

Println cannot print nothingness.

You can fix this in one of two ways ...

1)
Change speed() to
public String speed() {
return "30 mph";
}

OR

2)
Change
System.out.println(pet.speed());
to
pet.speed();

Don't do both changes


A note on naming ...
I'd name your existing speed() as printSpeed()
I'd name the revised speed() in (1) as getSpeed()

Designwise, maybe `public int getMPH()` would be better?

Thank you, it chose option 2, it works great.

 

[NickName]

[...]

Have you considered working through a book or tutorial? That would not
just explain the rules, it would explain when and how to use features.

Well, there's a little piece of doc that comes with JBuilder 2005,
which seems to be some sort of java tutorial, and I'm perusing it,
along the way, I have questions.

Thanks.

 

[Andrew Thompson]

[...]

Have you considered working through a book or tutorial? That would not
just explain the rules, it would explain when and how to use features.

Well, there's a little ..
(1)

...piece of doc that comes with JBuilder 2005,
which seems to be some sort of java tutorial, ..

Given the number (and level) of questions you are
asking, I'm guessing it is crap. But then, it would
be pretty astonishing if an IDE claimed to teach
you the underlying language.

(1) OTOH If you have a look over the one, the only,
and the official Java Tutuorial(2) I think you will notice,
it is anything but little.

(2) <http://java.sun.com/docs/books/tutorial/>

Andrew T.

 

[Lew]

I don't even understand this remark.

That's because it's nonsense. It is absolutely not true. In fact, it would
almost always be a design error to instantiate a subclass object from its
superclass.

Unless they are designed and intended to be overridden. For example,
java.util.AbstractSet provides a series of default implementations of
methods in the Set interface. Most actual Set implementing classes
extend AbstractSet and override some of the methods.

There are plenty of reasons not to make a method final, if you don't use it in
a constructor. The purpose of making a method final is to prevent an override;
if you want to allow an override then you must not make the method final.

It is conventional style. The compiler does not care, but human readers
who are used to reading e.g. Sun's Java code will find it easier to read
if you do stick to the conventions.

A class name should start with an upper-case letter and otherwise use camel
case. A method or non-constant variable name should start with a lower-case
letter and otherwise use camel case. A "constant" (final variables) name
should consist of all capital letters, and is the only name type that should
contain underscores (instead of the UpperCase of a camel-case identifier).

As Patricia said, these are conventions to help humans, not a requirement of
the language. Other aspects of the conventions include indentation,
brace-placement (some controversy there), comments and more.

You seem to be attempting to discover the rules of the language, and how
to use it, experimentally.

Have you considered working through a book or tutorial? That would not
just explain the rules, it would explain when and how to use features.

The Sun tutorials and books like _Thinking in Java_, _Java Head Start_, _Java
in 21 Days_, and others that have been recommended will help you.

- Lew