Assignment 6: Explorations in Object-Oriented Design

In the reading and lab on polymorphism, you explored a number of related classes that permitted you to build interesting two-dimensional layouts of characters. You were able to combine and recombine text objects because of Java's support of polymorphism. That is, if we treat every combination of text as an object that implements the TextBlock interface, then we can combine these objects arbitrarily.

The textual layout example also had a hidden agenda: To help you think about problems in a more object-oriented fashion. In particular, most beginning programmers, when asked to do some form of textual composition, focus on the methods that would compose pieces of text. In this example, we built objects that represent those composed pieces of text. The advantages of using objects included the ability to reuse a composed piece of text and a better ability to take advantage of polymorphism.

However, we left some aspects of the example unexplored in both the reading and the lab. Let's begin by building some new composition classes.

a. Write a class, Grid, which implements TextBlock and represents an w-by-h grid of a single character. You should provide one constructor, Grid(int width, int height, char ch). The width() method of the object you construct should return width. The height() method of the object you construct should return height. And the row(i) method should return a string of width copies of ch for all non-negative i less than height.

For example, given the following line,

  TBUtils.print(pen, new BoxedBlock(new Grid(7, 3, '*')));

the output will be

+-------+
|*******|
|*******|
|*******|
+-------+

You may choose to throw an exception in the constructor if the width or height are not sensible values.

b. Write a class, TruncatedBlock, which implements TextBlock and represents the truncation of a text block to a desired width. As you might expect, the constructor for this class should take a TextBlock and a width as parameters.

public class TruncatedBlock
  implements TextBlock
{
  /**
   * Create a new truncated block of the specified width.
   */
  public TruncatedBlock(TextBlock tb, int width)
  {
    ...
  } // TruncatedBlock(TextBlock, int)

  /**
   * Get the ith row of the block.
   */
  public String row(int i)
  {
    ...
  } // row(int)

  /**
   * Determine how many rows are in the block.
   */
  public int height()
  {
    ...
  } // height()

  /**
   * Determine how many columns are in the block.
   */
  public int width()
  {
    ...
  } // width()
} // class TruncatedBlock

For example, given the following program fragment,

  TextBlock block = 
    new VComposition(new TextLine("Hello"), new TextLine("Goodbye"));
  TextBlock block2 = new TruncatedBlock(block, 3);
  TBUtils.print(pen, block);
  TBUtils.print(pen, block2);

we see output something like the following

Hello
Goodbye
Hel
Goo

c. Write a class, CenteredBlock, which implements TextBlock and represents the result of centering a text block within a certain width, which is provided as a parameter to the constructor. That width should be no less than the width of the underlying text block, and your constructor should throw an exception if given an inappropriate width.

Your class should not attempt to look at the contents of the block which is centered. If that text is left justified, you simply center the left-justified text within your block.

For example, given the following program fragment,

  TextBlock block = 
    new VComposition(new TextLine("Hello")), new TextLine("Goodbye"))
  TextBlock block2 = new BoxedBlock(new CenteredBlock(block, 11));
  TBUtils.print(pen, block2);

we see output something like the following

+-----------+
|  Hello    |
|  Goodbye  |
+-----------+

In contrast, given the following program fragment,

  TextBlock top = new CenteredBlock(new TextLine("Hello"), 11);
  TextBlock bottom = new CenteredBlock(new TextLine("Goodbye"), 11);
  TextBlock block = new BoxedBlock(new VComposition(top,bottom));
  TBUtils.print(pen, block);

we should see something like the following

+-----------+
|   Hello   |
|  Goodbye  |
+-----------+

d. Write a class, RightJustified, which implements TextBlock and represents the result of right-justifying the underlying text block in a block of a width specified in the constructor.

e. Write a class, BlockPair, which implements TextBlock and represents two copies of the same block, side by side. For example, if the third row of block is "Hello", then the third row of new BlockPair(block) should be "HelloHello".

As written, our various text blocks are immutable. What would it mean to make them mutable? Let's consider those issues.

Add a setContents(String newContents) method to the TextLine class. As the name suggests, this method should set the contents of that block to the new value.

Some of the other classes may make assumptions about the immutability of text blocks. Identify where those assumptions are made and update the code so that it accommodates blocks that change.

Note that the only block that you will explicitly make mutable is TextLine. Your job is to update everything else so that when a TextLine changes, any block that contains that TextLine also changes.

You need only submit one set of code for parts A and B.

Here's a code fragment to help you think about changes.

  TextLine tb1 = new TextLine("Hello");
  TextLine tb2 = new TextLine("World");
  TextBlock compound = new BoxedBlock(new CenteredBlock(new BoxedBlock(
      new CenteredBlock(new VComposition(tb1, tb2), 7)), 15));
  pen.println("ORIGINAL");
  TBUtils.print(pen, compound);
  tb2.setContents("Someone");
  pen.println("UPDATED");
  TBUtils.print(pen, compound);
  tb1.setContents("Nice to meet you,");
  pen.println("RE-UPDATED");
  TBUtils.print(pen, compound);

And here's some corresponding output.

ORIGINAL
+---------------+
|   +-------+   |
|   | Hello |   |
|   | World |   |
|   +-------+   |
+---------------+
UPDATED
+---------------+
|   +-------+   |
|   |Hello  |   |
|   |Someone|   |
|   +-------+   |
+---------------+
RE-UPDATED
Something that indicates that there was an error, which may just be a missing line.

Fare-Vee corporation has decided to upgrade the software used in their grocery stores and has hired you to help implement their object model. (You may think it strange that they are hiring a relatively experienced programmer. However, the demand for programmers outstrips supply, and you are fortunate to have a general aura of competence.)

They've decided to start by having you model the items in the grocery store, focusing on how the consumer might think of purchasing those items. Here's their initial assessment of how they want the data organized.

+-Item----------------+   +-BulkFood----------+   +-Weight------+
| getWeight(): Weight |   | name: String      |   | unit: Units |
| getPrice(): int     |   | unit: Units       |   | amount: int |
| toString(): String  |   | pricePerUnit: int |   +-------------+
+---------------------+   | supply: int       |
 ^   ^   ^   ^            +-------------------+
 |   |   |   |
 |   |   |   +-----------------------------------+
 |   |   +----------------------------------+    |
 |   +--------------------+                 |    |
 |                        |                 |    |
+-BulkItem------------+  +-Package--------+ | +-ManyPackages---+
| food: BulkFood      |  | name: String   | | | type: Package  |
| unit: Units         |  | weight: Weight | | | count: int     |
| amount: int         |  | price: int     | | +----------------+
+---------------------+  +----------------+ |
 ^                                          |
 |                                        +-NonFood--------+
+-BulkContainer-------+                   | name: String   |
| container: String   |                   | weight: Weight |
+---------------------+                   | price: int     |
                                          +----------------+ 

That is,

As you might guess, each of the implementations of Item differs in its implementation of the toString, getWeight, getPrice, and equals methods. Note that the getWeight method returns the weight in whatever units the item uses. The getPrice method should return the price in cents.

Create a new package called com.farevee.groceries and create classes for these objects in the package.

Your predecessor has implemented the Units class to give you a head start. You can find that class at the end of this assignment.

Here's a program fragment that shows some of these classes in action.

  // The store has 20 pounds of bananas, priced at 50 cents per pound
  BulkFood bananas = new BulkFood("bananas", Units.POUNDS, 50, 20);
  // The store has 200 grams of saffron, priced at 1000 cents per gram
  BulkFood saffron = new BulkFood("saffron", Units.GRAMS, 1000, 200);

  // The customer adds three pounds of bananas to the cart
  cart.addItem(new BulkItem(bananas, Units.POUNDS, 3);

  // The customer adds a jar of 3 grams of saffron to the cart
  cart.addItem(new BulkContainer("jar", saffron, Units.GRAMS, 3);

  // The customer adds a bag of 1 gram of saffron to the cart
  cart.addItem(new BulkItem(saffron, Units.GRAMS, 1);

  // The customer adds a can opener to the cart, priced $3.489.
  cart.addItem(new NonFood("can opener", new Weight(Units.OUNCES, 2), 349);

  // The customer adds a box of oreos to the cart
  cart.addItem(new Package("oreos", new Weight(Units.OUNCES, , 12), 399);

  // The customer adds five 6oz packages of macncheez to the cart, each 
  // priced at 77 cents.
  cart.addItem(new ManyPackages(new Package("macncheez", 
      new Weight(Units.OUNCES, 6), 77), 5));

Note that if we were modeling this fully, we would decrement the supply of bananas or saffron when we added each to the cart. You do not need to worry about doing so, although you should also feel free to include that action in your code.

Fare-Vee are optimistic about your ability to implement the design above and have asked you to build a Cart class, too. They ask that you put that class in package com.farevee.shopping and that you include the following methods.

You may use whatever data structure you consider most appropriate to store the data in the cart - an array, a linked list you create, a Vector, an ArrayList, a LinkedList, or whatever else you decide is appropriate. Note that your choice of data structure will have a large effect on the ease of implementing the various methods, so choose thoughtfully.

Reflect on the design of the Fare-Vee project in Parts C and D. Some questions to get you started appear below. You should certainly address those questions, but you may also find it useful to consider others.

Comment on the differences in the relationships between BulkItem and BulkContainer on one hand, and Package and ManyPackages on the other. Each takes an existing class and adds information, but does so in different ways. What do you see as the advantages and disadvantages of each? When would you use one approach or the other?

Both Cart.remove, and Cart.merge require that you determine whether the name of an item matches a desired name. There are at least four approaches to achieving this goal. You could directly access the name field of each class. (That may be difficult, given that the name field probably isn't public, and you're working in a different package.) You could write a getName method for each class (or at least each appropriate class). You could write an equals(String name) method for each appropriate class. You could write a hasName(String name) method for each appropriate class. And, if you're doing that for each class, you might even put it into Item interface. There are also probably others. What do you see as the advantages and disadvantages of each approach?

Consider the differences between Package and NonFood. They appear to have the same fields. Does it make sense to make them separate classes? What other approaches could we use? Which would make most sense in terms of what we're describing? Which would make the most sense in terms of writing more maintainable code?

You can find another design at the beginning of http://www.cs.grinnell.edu/~walker/courses/207.fa14/suppl-prob.shtml. Comment on at least five differences between that design and the Fare-Vee design given in Parts C and D. In each case, indicate which choice you think is better and why. Please make sure that one issue you address is the choice between double and int values to represent prices.