 |
|
Homework J3Due: Friday, 4 March 2005 by 10 a.m. |
The objective of this assignment is to gain further familiarity with the design and implementation of classes to represent information by implementing and submitting a line representation named Line.
The previous assignment gave you experience with our implementation of class Line. Class Line was developed because we were looking ahead. We wanted the first class that you defined to be one with which your knowledgeable and that it be relatively simple and straightforward to implement. So your task for this assignment is to personally implement class Line according to the specification given in the next section.
When implementing software, being true its specification is the most important consideration. Users consider the specification to be a manual describing the software's features and how they perform. If the specification calls for a method toString() that returns a text representation of the line, then it is important both that the implementation provide the feature and that it be named as indicated. In this case, the feature should not be named tostring() or createString() -- it needs to be toString().
In our testing of your implementation we will be directly using all of the methods. We recommend that you pay attention to the preceding comments when you implement the Line specification.
None of your methods in the Line class should be static! We have not talked much about static vs. non-static in 101, but for now, do not define any of the methods in the Line class to be static.
Class Line represents a line using the standard form y = mx + b, where m is the slope and b is the y-intersect of the given line. As such the representation does not allow the modeling of vertical lines.
(b2 - b1) / (m1 - m2)
where m1 and m2 are respectively the slopes of the this line and that line, and b1 and b2 are respectively the y-intersects of the this line and that line,
Understand the role each of the methods and how they interact before attempting an implementation. Colloquially, you are going to need see both the forest and the trees to be successful.
A common practice when creating and testing code is to begin with the constructor, accessor, mutator and toString() methods -- you need to be able to first create and configure the objects if you are to then attempt their manipulation and having access to textual representation of an object makes its easier to debug errant code (i.e., you need to be able to see what's going on with the object).
Once these methods are correct then add your code for the facilitators. Because it is likely that the facilitators will make use of the other methods, knowing that the constructor, accessor, mutator and toString() methods are correct makes its easier to examine facilitator behavior.
Reading the text and reviewing the labs and class slides provide you with additional background on class development.
Both instructors presented simple classes in course meetings. The implementation of those classes can act as a template for your Line implementation. If you do not yet understand the sample classes, it will be extremely hard to independently develop a new class.
Suppose that you were developing a class Rational for fractions and this class had two data fields numerator and denominator. The typical beginning programmer correct places definitions for the attributes at the beginning of the class. However, many beginning programmers do not manipulate the attributes in their methods. Consider the following partial mplementation of Rational .
public class Rational {
private int numerator;
private int denominator;
public Rational (int n, int d) {
int numerator = n;
int denominator = d;
}
public void setNumerator (int n) {
int numerator = n;
} ...
The beginning programmer may think that the preceding code is correct and swears something must be wrong wrong with the computing system when the code segment
Rational r = new Rational(1, 2);
System.out.println( r );
r.setNumerator(3);
System.out.println( r );
produces output
(0, 0)
(0, 0)
rather than
(1, 2)
(3, 2)
What the programmer missed is that both the constructor and mutator defined local variables named numerator and denominator (see the int's at the beginning of all statements in the method bodies) and gave the indicated values to those local variables rather than updating the data fields numerator and denominator. The code should have been
public class Rational {
private numerator;
private denominator;
public Rational(int n, int d) {
this.numerator = n;
this.denominator = d;
}
public void setNumerator(int n) {
this.numerator = n;
} ...
or even better by using encapsulation
public class Rational {
private numerator;
private denominator;
public Rational (int n, int d) {
this.setNumerator(n);
this.setDenominator(d);
}
public void setNumerator(int n) {
this.numerator = n;
} ...
A second common mistake of beginner programmers is to have the toString() produce output. Consider the following toString() method for class Rational.
public String toString() {
String result = this.getNumerator() +
"/"
+
this.getDenominator();
System.out.println( result );
}
This implementation does not even compile -- there is no return of a string value. The purpose of toString() is to return a string representation to the invoking expression. Thus, a good implementation would be
public String toString() {
String result = this.getNumerator() +
"/"
+
this.getDenominator();
return result;
}
Explicitly test each constructor and method several times. This action does not guarantee their correctness but it does add to your sense of its reliability.
A good first program to test your class Line would be your program LineDemo.java from the second programming assignment. Another possibility is our implementation of LineDemo.java .
Submit Line.java when you are done.