Using superclass fields in subclass method

[lonegreyride]

Hi, I have a question about inheritance. I'm doing an assignment after a chapter on inheritance, and wanted to get something straight before I continue.

The question I'm currently doing is asking me to do the following:
-Create a Square class with private height and width fields, and a computeSurfaceArea method.
-Create a Cube class derived from the Square class with an added (private) depth field, and with an overriding computeSurfaceArea method.

Now, ignoring the fact that a square should have sides of equal length, etc, here's what I'm wondering:

In the Cube subclass's computeSurfaceArea method, I want to use the height and width that are inherited from the Square class along with my new depth field. The only way I can currently see to do this is to declare two new variables whose values come from the Square's getHeight() and getWidth() methods. This is the only way I can get the values of width and height. However, this, to me, seems to pretty much defeat the purpose of inheriting the fields from the parent class in the first place.

I'm basically just wondering if there's a more efficient way to do this without having the Square fields declared as protected instead of private. Thanks,

John

[venerik]

[wrong]
The Cube class is a sub class of Square. This means the Cube class has the same attributes and methods as the Square class plus more. So the Cube class can use the heigth and width attributes the same way the Square class does.

class Square {
    private int height, width;
}

class Cube extends Square {
    // Cube inherits width and height from Square and adds depth.
    private int depth;

    public int getSurfaceArea() {
        return width * height * depth;
    }
}

[/wrong]

[DarrylBurke]

@venerik : Did you try to compile the code you posted? Please do that and report back.

db

[DarrylBurke]

Now, ignoring the fact that a square should have sides of equal length, etc,

If I were rating your assignment, I'd deduct a lot of marks for ignoring that. In terms of design, it makes a lot of difference: for a square / cube you have just one numeric field for the side/edge; for a rectangle /rectangular solid you have two and three respectively.

Lose the habit of messing with requirements. As a budding programmer, your job is to translate the provided requirements into code / a working program.

here's what I'm wondering:

In the Cube subclass's computeSurfaceArea method, I want to use the height and width that are inherited from the Square class along with my new depth field. The only way I can currently see to do this is to declare two new variables whose values come from the Square's getHeight() and getWidth() methods. This is the only way I can get the values of width and height. However, this, to me, seems to pretty much defeat the purpose of inheriting the fields from the parent class in the first place.

I'm basically just wondering if there's a more efficient way to do this without having the Square fields declared as protected instead of private.

What do you have against protected fields? The whole purpose behind the keyword is to allow subclasses to inherit and use fields and methods that are 'protected' from any other classes (except other classes in the same package, but you probably haven't got to that yet).

db

[venerik]

o:o

Okay, maybe I should have asked myself the same questions as the OP did...

No, Mr Burke, I did not compile the code I suggested and no, the code does not compile correctly. :o :o

Most of the time I do compile it first but this time I thought I had it all clear in my head...

Very educational though. I don't think I will forget this any time soon.

@lonegreyride, please ignore my reply.

[JosAH]

I don't think you should extend the Square class with a Cube class; when a class D extends a class B there is an is a relation between those two classes, i.e. a D is aB. A Cube isn't a Square so a Cube shouldn't extend a Square class. This sounds like nitpicking but violating the is a relation is asking for trouble and I guess the Liskov Substitution Principle (LSP) can show more clearly why a Cube shouldn't extend a Square. You are effectively extending the Square class because it has a property 'side' or similar. You want to reuse (or abuse?) that property for your Cube class. You could also extend the Square class with a Circle class where the side property can be (ab)used for the radius of the Circle but that is not how extension of classes works semantically.

A Cube has a Square, it has six Squares actually but they're all equal so encapsulation of class Square in class Cube is the way to go.

kind regards,

Jos

[venerik]

Hi Jos,

Thank you for pointing us in the LSP direction. I found a nice article about it at objectmentor.com. It even uses a Rectangle and a Square class to explain why a Square should not extend a Rectangel (in C++ though).

Erik

[JosAH]

Thank you for pointing us in the LSP direction. I found a nice article about it at objectmentor.com. It even uses a Rectangle and a Square class to explain why a Square should not extend a Rectangel (in C++ though).

Yup, the square/rectangle problem (or circle/ellipse problem) is (in)famous for a violation of the is a relation; while mathematically a circle is an ellipse (or a square is a rectangle) in OO terms there isn't such a relation, especially not if one of the sides can be changed independently in the rectangle/ellipse class. A three dimensional body most certainly isn't a flat shape.

kind regards,

Jos

[Tolls]

Considering the poor OP probably has little control over the basic requirements of their task (beyond possibly commenting on the problems with it), it's a bit moot.
:)

According to the OP, the fields are private. And they're supposed to extend the Square into a Cube...OO principles be damned.
:)

Anyway, for the OP, since Square appears to have a getHeight() and getWidth() then simply use those. No need to store the height and width in the subclass.

(Note the last sentence took half an hour to finish...:))

ETA: Good lord, smiley overkill!

[JosAH]

Considering the poor OP probably has little control over the basic requirements of their task (beyond possibly commenting on the problems with it), it's a bit moot.

According to the OP, the fields are private. And they're supposed to extend the Square into a Cube...OO principles be damned.

Anyway, for the OP, since Square appears to have a getHeight() and getWidth() then simply use those. No need to store the height and width in the subclass.

Goody! I want to use wrappers for simple ints; I guess I'll use the Inet4Address class for it; that class can store four bytes too so it'll make an excellent parent class for my needs! ;-)

kind regards,

Jos

[Tolls]

I know that, and you know that...but whoever set the problem is a twit.

There's another one elsewhere on here involving some static method and printing things out. Never mind the method names the tutor provided! Coding standards? We don't need no steeking coding standards!

[JosAH]

I know that, and you know that...but whoever set the problem is a twit.

There's another one elsewhere on here involving some static method and printing things out. Never mind the method names the tutor provided! Coding standards? We don't need no steeking coding standards!

Indeed we don't; Java already is a sissy language when it comes to obfuscation and when it was hard to write it should be hard to read; why pamper the maintenance programmer? My advice: inherit from classes you'd least expect and don't use any of the superclass features; if needed override their methods and make them do something completely different. If possible change (i.e. recompile) the classes in the rt.jar file and make them do what you want and never, ever document it! Also duplicate as much code as you can, there isn't a Ctrl-C, Ctrl-V feature in your editor for no reason!

kind regards,

Jos

[lonegreyride]

Wow, thanks for all the discussion of this guys. Sorry I haven't been around, I posted this just before bed.

Anyway, the answer I've basically seen is that yes, I do either have to have those fields protected or use the getHeight() and getWidth() methods.

I also understand the issues you guys are having with the nature of the problem, but I'm doing my best not to lose any best practices for OOP, but rather to just ignore them for specific problems. I know the textbook and course material I'm doing pretty well, and the first set of exercises in each chapter usually test individual concepts, while later projects will bring them all together.

This was why I mentioned forgetting the fact that a square should have sides of equal length. If I were truly working with squares and cubes, there would be no need for 2, let alone 3 dimensions. I should only need the measurement of one side. As it is though, the problem is just using the word square as the class name as opposed to FourSidedFigure I suppose. Similarly, it's expected that the cube can have a depth of different value than the height or width.

As I said, I'm pretty familiar with my book, so I'm very certain that in this case they're simply testing my understanding of how to override a parent method. As it is though, they actually managed to get through the whole chapter without presenting a single example of actually manipulating inherited fields within the subclass itself, so my instincts were similar to venerik's. When I got the compile errors, and started fixing things, I just thought it looked much messier than I'd thought it would be.

So, to clarify what I've read so far, it's more efficient for me to simply call the get methods in the formula for surface area rather than allocating memory for height and width for each Cube object?

Again, thanks for all the replies and discussion. I think I'll pick up some good habits and methods of thinking from this forum. Cheers,

John