Hw3
Get started on exercises not solved in book
#7 Line class, for line between two Points. The methods are given, so we can piece together the class—
First draft
public class Line
{
//fields
//constructors
//methods
}
For a more
complete template, see pg. 530.
Second draft
public class Line
{
//fields
private
<type> <name>;
private
<type> <name>;
…
//constructors
public
Line(Point p1, Point p2) {
…
}
//methods
public
Point getP1() {
…
}
public
Point getP2() {
…
}
}
Fields: look at args of constructor for clues
Don’t forget “private”
#8
Another constructor for Line—use x1 and y1 for one Point, x2 and y2 for the other.
#11
No usable solution in appendix.
Start from Point.java on pg. 530.
Needs to “implement Colored”
Where Colored is the fixed up interface
public
interface Colored {
public Color getColor(); // or drop “public” here
}
This means we need a method public Color getColor() in Point, as well as “Point implements Colored” in the class declaration.
Suggestion from class: we could just return a fixed Color for all Points.
Yes, this would work: The JDK has color constants, like this one for blue:
public Color getColor()
{ return Color.BLUE; }
If we want one point to be blue, another to be red, etc., we need to add a new Color field to Point, and then return it in this getter, so add a field “color” (private!), and get it here.
Add: private Color color; // new field, so each Point has its own color
Look again at the interface:
public
interface Colored {
Color
getColor();
}
Note that it has only one method, whereas our previous examples have multiple methods:
public interface Vehicle {
String getMake();
String getVIN();
};
public interface
Shape {
double getArea();
double getPerimeter():
}
Also, these have nouns as names, whereas “Colored” is not a noun, but rather a modifier of a noun.
We say
A Truck IS-A Vehicle (it has getMake() and getVIN() as methods)
A Rectangle IS-A Shape (it has getArea() and getPerimeter() as methods)
So for Colored it would be (after “Point implements Colored”)
A Point IS-A Colored (it has getColor() as a method)
This is incomplete English, so to make it complete, add “thing” or “object”
A Point IS-A Colored thing
A Point IS-A Colored object
But most people leave the extra word out, tolerating the bad English.
Interfaces with just one method often have noun-modifier names, whereas multi-method interfaces usually have nouns for names. The one method of Colored is describing one aspect of objects, that is, their color. We could have “A Rectangle IS-A Colored” if we added getColor() to Rectangle and “implements Colored” to its class declaration.
Stupid analogy: boy scouts have merit badges for things they have proved they can do: archery, setting a fire without matches (I’m making this up), etc.
We can think of “implements Colored” as a merit badge on the class it’s declared in: If a Point implements Colored, it knows how to return a Color via getColor(). That capability is worth a badge!
There was discussion of whether IS-A is really Java. No, it isn’t. It’s bigger than Java itself, a description of object type relationships that is used in all object-oriented languages: Java, C#, C++, …
Although IS-A isn’t built into Java, but is just a description used by practitioners as a sort of shorthand, the “implements” keyword is definitely understood and used by the Java compiler.
We discussed how the compiler enforces the contract of implements. “public class Point implements Colored” means that when Point.java is compiled, the compiler looks at Colored.class to make sure that all its promised methods are there in Point.java (i.e. getColor() in this case), and fails the compile if not. Try it out!
An Automobile IS-A Vehicle
A Truck IS-A Vehicle
Where the Vehicle is something that has a VIN and a make: We say this in Java this way:
public interface Vehicle {
String getMake();
String getVIN();
};
Because Automobile already has getMake() and getVIN(), we can write in Java
So
public class Automobile implements Vehicle {
… just as before: has methods getMake(), getVIN()
}
public class Truck implements Vehicle {
//Truck fields, constructor(s), methods (must include getMake(), getVIN())
}
So why bother?
Now we can write code that handles both cars and trucks, using their common behavior.
Example: countFords: loops over a Vehicle[] array, counting Fords regardless of whether they are cars or trucks
Example: findVIN: loops over a Vehicle[] array, to see if it has a certain car or truck with given VIN.
public interface VINed {
String getVIN();
};
public class
Automobile implements VINed {
…
}
public class Truck
implements VINed {
…
}
Another class: Trailer
implements VINed (trailers need VINs, even if they have no “make”)
…means Trailer has
getVIN()
Now we can write code using
getVIN() across any group of objects whose classes implement VINed.
For example, the findVIN method previously discussed, which searches for a certain VIN across a group of objects (now all VINed objects)
What methods does Shape promise? getArea() and getPerimeter().
Way to say it in Java:
public interface
Shape {
double getArea(); //
or put “public” first as book does
double getPerimeter():
}
Circle IS-A Shape
Way to say it in Java:
public class
Circle implements Shape {
… with methods getArea(), getPerimeter
}
Similarly for Rectangle, etc.
Here we see that different code is used for the area computation, depending on whether the shape is a circle or a rectangle, etc.
Circle: field
radius, area = pi * radius * radius, returned by getArea()
Rectangle: fields: width, height, area = width * height, returned by getArea()
Shape: no fields, but getArea() gets calculated based on the underlying type of the object
Payoff of doing all this: we can write code that can loop across a group of objects of different types, calling getArea() and/or getPerimeter, because they are all known to have these methods.
For example, we could sum areas across a group of Shape objects
Class exercise on Interfaces, Shape example