Inheritance

[colin shuker]

Hi, I'm doing a test, and I need to write a set of classes that represent a Circle, Triangle and Rectangle, and then allow user to find the area of any of them.

I,ve added a 'name' field too, my plan is to just use an abstract class Shape, and let the others extend it, please can you tell me if the code below is well structured, and if it could be improved.

Here is the ShapeInterface:

public interface ShapeInterface {
 
public abstract String getName();
public abstract double getArea();
}

Here is the Shape class:

public abstract class Shape implements ShapeInterface{
 
public String name;

public Shape(String name) {
this.name=name;
}
 
public String getName(){
return name;
}

public abstract double getArea();
}

Here are the 3 subclasses, Circle,Triangle and Rectangle

 
public class Circle extends Shape{
 
double radius;

public Circle(double radius){
super("Circle");
this.radius=radius;
}
 
@Override
public double getArea() {
return Math.PI*radius*radius;
}
}
 

 
public class Triangle extends Shape{
 
double base;
double height;

public Triangle(double base,double height){
super("Triangle");
this.base=base;
this.height=height;
}
 
@Override
public double getArea() {
return 0.5*base*height;
}
}
 

 
public class Rectangle extends Shape{
 
double base;
double height;

public Rectangle(double base,double height){
super("Rectangle");
this.base=base;
this.height=height;
}
 
@Override
public double getArea() {
return base*height;
}
}

Thanks

[Merrill Higginson]

Looks good. The only change I might suggest would be to eliminate the abstract Shape class and just have Triangle, Circle, and Rectangle implement the Shape interface directly. The advantage of this is that if you start coding for these objects in a complex application, you may find that it would make more sense to make these objects part of some other class hierarchy.

Since Java does not allow multiple inheritance, don't "waste" your one shot at having a class inherit from another class. By implementing the interface only, your objects are free to inherit from another class that might be more appropriate and provide more benefits for code reuse. The rule of thumb provided by Joshua Bloch in his book Effective Java is "Prefer interfaces to abstract classes".

[colin shuker]

I see your point, but what about the 'name' variable, I would have to declare this field in the 3 subclasses wouldn't I?

My code makes use of code reuse, what do you think?

[Merrill Higginson]

Yes, having an abstract class does save you from having to code a name variable and getter/setter in each class. That's a point in favor of an abstract class. The trade-off, though, is that the class becomes less flexible. You stated at the beginning of your first post that the assignment was to have each class calculate the area. The interface accomplishes that beautifully without an abstract class. The name attribute was something you added as an afterthought, and is peripheral to the real point of the class. I'd say it's not worth making the class less flexible.

This is obviously a simple application, so it doesn't really matter, but in the real world, it's a good idea to keep classes free of dependencies on a static hierarchy whenever possible.

Here's an example of what I'm talking about: Suppose now you want to draw each of these shapes on a screen. You now have a whole lot of other things to take into consideration, such as coordinates, background color, translucence, etc. Since all you used was a interface to calculate the area, you're free to have these classes implement as many other interfaces as you want (e.g. drawable, expandable, movable, etc.). Now suppose you have a whole lot of default behavior you want each of these shapes to inherit that has nothing to do with area, and it would be really convenient just to have the shape classes inherit from a class that embodies all that default behavior. If the shape classes already inherit from an abstract class, you're just out of luck, because a Java class can only inherit from one superclass. I think you can see why you don't want to play the abstract class card until you really need it.

You just have to weigh the benefits on either side and make your decision. If, for example, there were ten properties shared by all classes, that would probably swing my decision over to using an abstract class. With only one property, though, I think I'd prefer to keep the class more flexible and just do the extra work of coding the property in each class.

[Campbell Ritchie]

As for names, try getClass().getName(), then try substring(lastIndexOf("."))

BTW: what I quoted won't compile in its present state.

[colin shuker]

Thanks for your input, I didn't use the last getClass() part, since it is now unnecessary as I have removed the abstract class so that the 3 classes now implement getArea() and getName(), as below:

public interface Shape {
 
public abstract String getName();
public abstract double getArea();
}
 

public class Circle implements Shape{
 
double radius;

public Circle(double radius){
this.radius=radius;
}
 
public double getArea() {
return Math.PI*radius*radius;
}
 
public String getName() {
return "Circle";
}
}
 

public class Triangle implements Shape{
 
double base;
double height;

public Triangle(double base,double height){
this.base=base;
this.height=height;
}
 
public double getArea() {
return 0.5*base*height;
}
 
public String getName() {
return "Triangle";
}
}
 

public class Rectangle implements Shape{
 
double base;
double height;

public Rectangle(double base,double height){
this.base=base;
this.height=height;
}
 
public double getArea() {
return base*height;
}
 
public String getName() {
return "Rectangle";
}
}

Does that look better? Thanks

[Campbell Ritchie]

Miss out "abstract" in your interface method declarations. Because it is an interface, the "abstract" bit is taken for granted and can be omitted.
No problem about getClass().