I am trying to create a Star class which will allow me to create and draw stars. I tried extending Polygon, but the constructor for the polygon is:
Polygon(int X-Coordinates[], int y_cootdinates[]. int numPOints);

And I need to use double numbers as the cooridinates. Any way around this problem, or should I extend from another class when creating my star class? THanks

By the way I am trying to do this in Java

I don't see the problem, as you can cast from integers to doubles, and create an additional constructor for the case where you want non-integral coordinates.

Since you'll have to call that constructor from your constructor, it seems you can't get around the integer problem.

- "happy to correct Psion" taubz

If you absolutely need to have a floating point value, choose to what accuracy (ie I'll use 3dp. here) and then multiply the doubles by 1000(or whatever value is appropriate) and cast to ints. Just
remember to overload functions that return information about it to return values that have been properyly divided again. - Not ideal, but should be functional.

That's an abuse of object oriented design. Besides, you don't know what else the polygon class does. It might be responsible for drawing the shape, in which case it's important for it to have the correct numbers.

I thought the whole point of inheritance was that you could extend a class to do stuff that it wasn't originally designed to do? So it seems to me that you need to make a new class that extends Polygon. You should then make your constructor accept double-precision numbers. The constructor can then cast to integer and call the Polygon constructor.

You will also need to implement all of the methods that require double-precision numbers.

walker222, it sounds like you're on the right track. I recommend that you find a good Java tutorial and use it to get a good foundation of knowledge in classes. I think you can find some on the Resource Links page, http://www.tpu.org/tea/Home./cg-8

RDD and Mike, I think you're overlooking an important part of programming design.

Functions and classes and the like shouldn't be merely reduced to their signatures. You could say that a sqrt function is merely a float=>float function, and if I substituted any float=>float function for sqrt it would be okay. That's clearly false: the author of the sqrt function is under "contract" with the rest of the world that the function will return the square root of its input. Violating the contract by replacing sqrt with another function with the same signature might compile, but it's bad programming practice and will likely cause problems later.

The same applies to classes and, in this case, constructors. The polygon class is not merely a class that contains an array of integers (if that is what it does). Instead, the polygon class is a class that stores an array of coordinates, and not just any coordinates, the coordinates of the polygon.

This gets a bit more complicated with inheritance, but I'll skip to the conclusion...

Calling the Polygon constructor from the Star constructor with numbers that are *not* the coordinates of the Polygon that this object is to represent is a violation of the contract that the Polygon class makes with the rest of the world. Violating a contract is a good way to cause problems in the future.

Whenever you feel yourself trying to circumvent someone else's design, you're headed for trouble.

- taubz

OK, it was an idea, I pointed out it was a bad one when I wrote it.

It also might be helpful if I we were told a little more about what he'd be using the polygon class for.

taubz, what then do you suggest for walker222 to do? Should he make a whole new class that merely instantiates a new Polygon class and proxies function calls? That seems like a great waste considering that nearly all of the functionality of the Star class will be derived from the Polygon.

I don't see it as a break of contract for a specific shape class to inherit from a general shape class.

One should not derive a double-based shape class from an integer-based one. Yes, he should start from scratch.

> I don't see it as a break of contract for a specific shape class to inherit from a general shape class.

That wasn't what breaks the contract. I refer you to: "Calling the Polygon constructor from the Star constructor with numbers that are *not* the coordinates of the Polygon that this object is to represent is a violation of the contract"

- taubz