Repeat A09, only this time make the cone its own class and create instances of it.
Concepts: Constructors, instance methods, encapsulation
Textbook: 4.3 - 4.5
You'll need to write two classes/files for this assignment. Normally, you'd create
Cone and then some other class--
ConeTester, perhaps--that creates
Cone instances. However, since you're going to turn in your Cone class to Tamarin, you'll need to give it the unfriendly name of
This class models a cone. It should have at least two
private instance variables for the radius and height; you may have more, if you wish. It should then have at least the following public constructor and methods:
- public UsernameA16(double radius, double height)
- public double getRadius()
- public void setRadius(double r)
- public double getHeight()
- public void setHeight(double h)
- public double getSlantHeight()
- public double getVolume()
- public double getLateralSurfaceArea()
- public double getTotalSurfaceArea()
Remember that your methods must match these signatures exactly. Note how, unlike in A09, the methods no longer take parameters. This is because every cone now already knows its own radius and height, so you don't need to pass this information to the methods anymore.
UsernameA16.java should only model a cone and not do any direct communcation with the end user. So don't do any printing or user input in this class.
Error-checking of passed values is optional. For instance, you could prevent negative values for the radius by setting it to 0 or taking its absolute value instead; but this is not required--you can allow another programmer to make a cone with a negative radius if they really want to.
Then write a separate class with a
main method that serves as a user interface to testing your cone class. You can prompt the user to enter a radius and height and create a cone from it, producing output similar to A09's. You don't have to get the information from the user, however; you could just hard-code a few tests.
Make sure you test each method of your cone and confirm that it works correctly. This means you will need to change at least one cone's radius and height and print out its details again in order to test
You will not submit this file; it's just to help you ensure that your cone implementation is correct.
Your output will depend on how you wrote your ConeTester class. It could be similar to A09, but it doesn't have to be.
What to Submit
UsernameA16.java file to Tamarin.
Grading [5 points]
- 1 - Compiles
- Your program compiles successfully (no errors)
- 0.5 - Encapsulated instance variables
- All your instance variables are private.
- 0.7 - Constructor
- Has a public constructor that takes two doubles (radius and height, in that order).
- 1.2 - Accessor (get) and mutator (set) methods for radius and height
- 0.2 each for two get methods; 0.4 each for two set methods.
- 1.6 - Accessors for slant height, volume, lateral surface area, and total surface area.
- 0.4 each. All methods are instance methods (not static) and exactly match the method signatures given above. Returned values are correct even after changing the dimensions of the cone using the set methods.
- So wait... the program I turn in doesn't really do anything?
- That's correct. With no main method, it won't be possible to run your cone class, and so it won't itself produce any output.
Instead, you're practicing writing a class that you could then use in another program that needs to model cones. You can write such a program if you want to... but it would be sufficient to just write a testing program that:
- creates a single cone
- calls all its get methods and prints or confirms that the results are correct for a cone of that size
- change the cone's dimensions with the set methods
- calls all the get methods again, to be sure that the results are now correct for the changed cone
UsernameA16 cone class will be more like
Monster in the lab demo code (usually written on the right side of the board in sections 001 and 002). Your tester class (which you won't be submitting) is more like the
MusicApp (usually on the left side of the board).
- Are we supposed to write
/** javadoc */ documentation for all these methods?
- You don't have to. The coding standards for the course mention that you can forgo documenting "getter" and "setter" methods like these. The reason for the exception is that, if you're documented the class and so explained the context, the method signatures are usually explicit enough to explain what these simple methods do.