At this point in your career, you should be thinking about more than just what functions to include in an object and how to implement them. In particular, it is important to consider
The my own solution to this assignment, I found that
I needed a wide variety of utility classes. These included a variant
Assert class that threw exceptions rather than
terminating the program. I also chose to use a newly-defined
BoundsException for most of the errors pertaining to my
The my own solution is somewhat excessive. I tend to include many preconditions and throw exceptions whenever the smallest error occurs. I also try to ensure that my data structures remain coherent when errors occur. For example, if someone tries to insert the 10th row in a two-row matrix, we shouldn't change the original matrix. (I don't think that many of you do, but that's a warning.) Note also that exceptions are the only ways in which your utility classes should indicate errors. Only your main/interface class should print warnings!
A small design issue was the choice of indices to use. While Java uses zero-based indexing for its arrays and vectors, I felt that one-based indexing was more appropriate for our class, as most people describe arrays with one-based indices (or at least the linear algebra text on my shelf does).
A similar concern was the ordering of row and column. I had originally
designed a Point class (giving discrete (x,y) points). However, I
noted that Cartesian coordinates and matrix indices have "opposite"
orientations. On the Cartesian plane, we list the horizontal offset
first (the x value). In matrices, we list the vertical offset first
(the row). This led to the design of a
which I used in place of the
Pair class from the assignment
Point class I had originally designed.
Did I have problems building my class? I spent awhile deciding on
appropriate preconditions for
fillLine. For example,
I needed to think about whether offsets could be 0 and whether we had
to end at the final point, or simply "beyond" it. I chose to allow
offsets of 0 (but only for one of the offsets) and to require that we
end at the final point.
I also wondered about the appropriate restrictions to (and meaning of) insertion of rows and columns. I decided that insertion before another row or column was appropriate. I also decided to allow insertion directly after the last row or column using the same method. Implementing this correctly ended up being more difficult than I had expected, and I may have been better off disallowing it or providing a separate method.
One big concern was the effect of these operations when the matrix was empty. In some sense, they seemed to be the only available mechanism for expanding an empty matrix. Without them, empty matrices are completely useless. However, it was clear that insertion into an empty matrix would be particularly difficult and potentially unclear. In the end, I chose utility over ease of coding.
The method that took me the most time to get right was my
method, which I provided as an alternative to
I found it quite easy to define
toString() using the standard
methods associated with
java.util.Vector. However, that output was not
appealing or easy to read. Hence, I worked on a two-dimensional alternative.
Making sure that the matrix was evenly spaced took some time and eventually
required me to write
The helper class
to handle some of the string formatting.
Should your version have been as excessive as mine? Certainly not. Would I be happy if it were? Certainly.
Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.
Source text last modified Sun Feb 22 22:40:25 1998.
This page generated on Tue Jan 12 11:44:39 1999 by SiteWeaver.
Contact our webmaster at email@example.com