Partial Solution and Comments for Assignment 1

Overall, Assignment 1 was quite well done. The average was a B. Documentation was well presented, and almost all implementations worked satisfactorily. Testing was reasonably comprehensive, and the test plans I saw were clear. Where several groups made mistakes was with design, as the following comments suggest.

Solution Hints

There were many acceptable solutions to Assignment 1. The best solutions had classes roughly like the following:

CUSTOMER: the ADT of customers. Customers have all the information mentioned in the assignment: names, emails, credit cards, etc. They also have passwords.
PRODUCT: most groups chose to implement a specific type of product, and thus had a BOOK or VIDEO class. That's the best way to go for this assignment. For assignment 2, I'd create a (deferred) PRODUCT class and inherit from it with specific subtypes (e.g., BOOK, VIDEO).
CUSTOMER_DATABASE: an array/list/tree of customers. The customer database knows how to load and save customers into a file, and provides search facilities.
PRODUCT_DATABASE: an array/list/tree of products (e.g., BOOKs). The product database knows how to load and save the product database, and provides search facilities. It also has an attribute for storing the last product that has been found by a search.
MONSTRO_MART: the root class. It provides login features, the user interface (which could be just a simple menu) and keeps track of the last 5 purchases made by the current customer (this info. could be saved in a file after the customer logged out). Another design option here would be to have the customer themselves keep track of their last five purchases. There doesn't appear to be any criteria for deciding between one or the other option here.

No further classes are really needed to solve the problem. A PASSWORD class is a possibility, but it is not required.

No inheritance is necessary in this solution. Class MONSTRO_MART will have a customer database, a product database, a customer (the current customer logged in), and numerous user interface features.

Common Problems

A number of reoccuring problems appeared in many solutions.

Information hiding: many solutions completely ignored info. hiding, making all features public. This is dangerous, as it allows clients to make use of details we'd rather leave private. In future assignments, pay careful attention to whether features should be public, private, or selectively exported. The default (public) doesn't always apply.
Require and ensure: some groups did not use require and ensure clauses, as the assignment asked. Some groups used them only to check for void arguments, which is useful but limited. Similarly with class invariants: a good invariant clause for the product and customer databases is that all products/customers should be unique. While this is hard to state precisely, it could be stated as a comment.
Poor class naming: several groups used verbs for class names, e.g., SEARCH, REGISTER, LOGIN, BUY. Classes never have verbs (actions) for names. Routines (i.e., functions and procedures) will have verbs for names, because they do things. Classes don't ``do'' something -- they're abstract data types. Thus, it is more appropriate to use nouns or adjectives for class names.
If you ever see a class with a name that is an action, question it -- it's either poorly named, or it isn't a class.
Classes with no attributes: some classes that I saw had no attributes; they consisted of one or more routines. More often than not, these aren't classes -- they're routines masquerading as classes, and should be merged with other classes. If you have a class without any attributes, think very carefully about your design -- you're probably doing something wrong.
Classes that aren't classes: several groups wrote classes that simply aren't classes. For example, SEARCH. SEARCH is an algorithm, not an ADT. It should be a routine, instead of a class, and it should belong to the classes that use it, e.g., the customer or product database. Similarly, REGISTER is a routine and not a class.
Improper use of deferral: some groups used deferred classes. We'll talk about deferred classes in lecture, but they're really only useful when you want to provide an interface that many different subtypes can implement. There was no need to use subtypes in this assignment, hence deferral was (mostly) inappropriate.