Inheritance and lousy Frame

Discussion in 'Java' started by NickName, Jan 10, 2007.

  1. NickName

    NickName Guest

    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.
    NickName, Jan 10, 2007
    #1
    1. Advertising

  2. NickName wrote:
    > 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.
    Andrew Thompson, Jan 10, 2007
    #2
    1. Advertising

  3. NickName

    Oliver Wong Guest

    "NickName" <> wrote in message
    news:...
    > 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
    Oliver Wong, Jan 10, 2007
    #3
  4. NickName

    Ian Wilson Guest

    NickName wrote:
    > 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);
    }
    }
    }
    ------------------------------------------------
    Untested. Caveat emptor. Batteries not included.
    Ian Wilson, Jan 10, 2007
    #4
  5. NickName

    NickName Guest

    Ian Wilson wrote:
    > NickName wrote:
    > > 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);
    > }
    > }
    > }
    > ------------------------------------------------
    > Untested. Caveat emptor. Batteries not included.


    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, Jan 11, 2007
    #5
  6. NickName

    NickName Guest

    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);
    }

    }
    NickName, Jan 11, 2007
    #6
  7. NickName

    Lew Guest

    NickName wrote:
    > 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
    Lew, Jan 11, 2007
    #7
  8. Lew wrote:
    > NickName wrote:

    .....
    > > System.out.println("My dog: " + getName());
    > > System.out.println("is + " + getAge() + "now.");

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


    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.
    Andrew Thompson, Jan 12, 2007
    #8
  9. NickName

    Ian Wilson Guest

    NickName wrote:
    > 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?


    <snip>

    > 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).
    Ian Wilson, Jan 12, 2007
    #9
  10. NickName

    NickName Guest

    Ian Wilson wrote:
    > <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.
    NickName, Jan 12, 2007
    #10
  11. NickName

    Ian Wilson Guest

    Re: void type not allowed in println(). Was Re: Inheritance and lousyFrame

    NickName wrote:
    >
    > 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?
    Ian Wilson, Jan 12, 2007
    #11
  12. 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
    Patricia Shanahan, Jan 12, 2007
    #12
  13. NickName

    NickName Guest

    Re: void type not allowed in println(). Was Re: Inheritance and lousy Frame

    Ian Wilson wrote:
    > NickName wrote:
    > >
    > > 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, Jan 12, 2007
    #13
  14. NickName

    NickName Guest

    Re: void type not allowed in println(). Was Re: Inheritance and lousy Frame

    Ian Wilson wrote:
    > NickName wrote:
    > >
    > > 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, Jan 12, 2007
    #14
  15. NickName

    NickName Guest

    Patricia Shanahan wrote:
    > [...]


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

    >
    > Patricia
    NickName, Jan 12, 2007
    #15
  16. NickName wrote:
    > Patricia Shanahan wrote:
    > > [...]

    >
    > > 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.
    Andrew Thompson, Jan 13, 2007
    #16
  17. NickName

    Lew Guest

    NickName wrote:
    >> a) subclass object must be instantiated from the super class;


    Patricia Shanahan wrote:
    > 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.

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


    Patricia Shanahan wrote:
    > 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.

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


    Patricia Shanahan wrote:
    > 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.

    Patricia Shanahan wrote:
    > 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
    Lew, Jan 13, 2007
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Søren M. Olesen
    Replies:
    0
    Views:
    556
    Søren M. Olesen
    Nov 13, 2003
  2. Microsoft
    Replies:
    3
    Views:
    677
    Hugo Wetterberg
    Oct 4, 2004
  3. JAW
    Replies:
    2
    Views:
    551
  4. geoff moyle
    Replies:
    1
    Views:
    287
    Dennis Lee Bieber
    Oct 2, 2003
  5. Rouslan Korneychuk
    Replies:
    8
    Views:
    568
    Rouslan Korneychuk
    Feb 10, 2011
Loading...

Share This Page