This is my summary of what the various Teams gave me on Monday, October 11, 1999.
I don't know how to make this clearer: You will not get the project done if you don't keep up on the parts of the project! Your goal for today was reasonable:
Nothing turned in. Goal was start of implementation of GUIs.
I'm a little bit confused. It appears that this one class serves the purpose of the network, the mailbox, and the maildrop. I'd prefer to see separate classes (and, preferably, separate interfaces).
I'd also like to see something about constructors.
Given that you've tied everything together, you need to more carefully document what needs to be done in what order. For example, what happens if I try to list folders without connecting to the server or logging in?
It doesn't compile. (I know, that wasn't required, but it woulod have been nice.)
You haven't created the accompanying exception classes. You also haven't told me much about when exceptions might be thrown.
Some minor notes:
getFolderContentsreturns an array of strings rather than an array of message headers (or even some form of
getMessagereturns a string rather than a
/** * Yadda yadda yadda. * * @exception ConnectionException * when ... */
Conditions relate to
isRuleTrueneed some parameters? For example, don't you want a mailmessage to consider?
Conditionclass have a
Grade: Very good
Short Notes: Most of what I expected in the design. I would have preferred a separate interface, rather than just a class. Otherwise, provides sufficiently many details.
I do wonder how
setPhoto relates to the other stuff.
One possibility is to add a separate
interface (and, eventually, a class). That could then include the
Summary: This group seems to have missed the point. While they created a number of classes, none of the classes is sufficiently well documented for it to be useful.
Discussion: As I mentioned in the notes on the first round, it's difficult, if not impossible, to predict all the options that the various classes would need. Hence, I suggested having generic methods that get and set particular kinds of options (boolean, string, general object). The group seems to have ignored that advice without giving an explanation as to why.
The classes they've created are not very useful in their current form.
Their code did not compile. (I've updated it so that it does.)
Although it became clear from discussion that their class would need to store information on ``preferred filters'', they have made no attempt to do so.
Some more specific comments:
Addressclass, it's not clear why
Nothing turned in.
Nothing turned in. However, since they were building the textual user interface, they were not required to turn anything in. The were, however, supposed to be prepared for discussion. We'll see how that goes.
11 October 1999
13 October 1999
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.
This page may be found at http://www.math.grin.edu/~rebelsky/Courses/CS152/99F/Project/proposals.02.html
Source text last modified Wed Oct 13 09:39:30 1999.
This page generated on Wed Oct 13 09:39:54 1999 by Siteweaver. Validate this page's HTML.
Contact our webmaster at firstname.lastname@example.org