Graphs Versus Objects

Objects Of My Affection

2008 seems a good time to experiment with a truly futuristic idea—an online store! First, we'll need sellers and buyers (using a Person class with a name field) with something to sell and purchase. Figure 1, the object-oriented UML class diagram for our example, depicts the knowledge representation.

Here we declare the representation in Java. Note the mixture of representation with actual processing. As the complexity grows, this becomes difficult to separate and improve. We use line numbers to denote that the following is an abridged code version:

3 public class PurchasableItem {
5 private float cost;
6 private String manufacturer, label;
8 public PurchasableItem (String label, float cost, String manufacturer) {
// Call appropriate setters
13 }
// Typical getters and setters follow ...
35 }

Figure 1: UML class diagram.

Add a Transaction class and we're ready to open our doors:

3 public class Transaction {
7 private Person buyer, seller;
8 private PurchasableItem containsItem;
9 private Date sellDate, shipDate;
10 private String label;
12 public Transaction(Person buyer, Person seller, PurchasableItem containsItem, Date sellDate, Date shipDate) {
13    super();
14    setBuyer(buyer);    // Call appropriate setters
                          // with remaining parameters ...
19  }
59 }

Let's watch our first sale happen as we create instances provided by the class definitions. (The full code is online.)

//Matt ...
Person seller = new Person("Matt Fisher");
// ... is selling his special toaster ...
PurchasableItem toaster = new PurchasableItem("High-wolf shiny toaster", (float)49.95, "Dualit");
pItems.add(toaster); 
// pItems is a HashSet of PurchasableItems
// John ...
Person buyer = new Person("John Hebeler");
// ... is buying the toaster very soon!
Calendar sellDateCalendar = Calendar.getInstance();
sellDateCalendar.set(2008, 3, 24, 10, 0, 0);
Date sellDate = sellDateCalendar.getTime(); 
// similar code follows for shipDate
Transaction tran = new Transaction(buyer, seller, toaster, sellDate, shipDate);
transactions.add(tran);

Keeping track of our marketplace requires some custom queries that interrogate our objects:

// Now, how many items has John bought?
     int count = 0;
     for (Transaction t : transactions) {
         if (t.getBuyer() == buyer) {
             count++;
         }
     }
   System.out.println("John has purchased " + count + " item(s)");
     // Now, what has John bought?
     count = 0;
     System.out.println("John has bought:");
     for (Transaction t : transactions) {
         if (t.getBuyer() == buyer) {
           System.out.println("   " t.getContainsItem().getLabel());
         }
     }

The resulting output is:

John has purchased 1 item(s)
John has bought:
   High-wolf shiny toaster
 

Our objects quickly created a basic solution. Additional queries require additional coding. This works to constrain the variety and power of the questions. As we continue to code, we realize we created a proprietary solution. Integration becomes difficult in two ways—more of the same instances and different types or classes of instances. The former requires custom integration code and is subject to our chosen storage method (for this example, it is merely in-memory arrays). The latter, different type of classes, creates an N2 problem as we write custom code to combine objects from a different class. (Imagine that a similar solution did not create a transaction class but rather a user purchase class.)