Data Items for the Home Inventory Project

What information will we need to store for the various types of objects in our home inventory? No matter what type of object we are recording, we will want to store the following data:

  1. type of object,

  2. date of acquisition,

  3. price,

  4. description,

  5. category (e.g., office furniture, kitchen appliance).

While we'll have to maintain the above data for every object, we'll also need to keep track of other information on some types of objects. Of course, the exact form of that extra information will depend on each object's type. After some thought, I have come up with the following types of objects that we might want to keep track of (in no particular order):

  1. “Basic” objects, for which the above data are sufficient;

  2. “Music” objects (e.g., CDs, LPs, cassettes);

  3. computer hardware;

  4. computer software;

  5. other electric and electronic appliances;

  6. books;

  7. kitchen items such as plates and flatware;

  8. clothes and shoes.

Of course, each of these types has different additional type-specific information, which is why we need the individual types in the first place.

Undoubtedly you can think of a number of other kinds of objects that don't fit exactly into one of the listed types. However, I think most of these other kinds are close enough to one of the above types that we can use one of those listed without too much strain. For example, what about jewelry and art objects? It seems to me that the “Basic” type is fine for both of these, as we have to keep track of the basic information needed for all objects (value, date of acquisition, description, and category) and not much else.

Choosing Categories for Items

This brings us to a very important point in the design of any program, especially an object-oriented one: deciding how to fit the nearly infinite possibilities of real-world entities into a necessarily limited number of categories in the program. I wish there were a hard-and-fast rule I could give you so you wouldn't have to make this decision for every program you write; unfortunately, however, this isn't possible, precisely because there are so many possibilities in the real world. The best I can do is give guidelines and examples.

Consider the example of LP records or cassette tapes. In this case, I think it's pretty obvious that an LP or a cassette tape is similar enough to a CD that using the “Music” type for either of these other types of sound recording is appropriate.[1] How did I make this determination?

[1] Of course, if you still have 8-track tapes, you probably also need a “lava lamp” category.

  1. The purpose of a CD is to contain music or speech. This is also the purpose of an LP or cassette.

  2. The information that we might want to store about a CD includes artist, title, and track names. These are also appropriate for an LP or cassette.

Note that the storage medium and other surface similarities among objects aren't significant in this analysis. In fact, a CD-ROM, which uses exactly the same storage medium as a music CD does, is a completely different type of object from a music CD and needs to be categorized under “computer software”. That's because the purpose of the objects and the information we need to store about these two different kinds of CDs are completely different.[2]

[2] This is an oversimplification because both music CDs and CD-ROMs can be stored in the same “CD holder”, whereas cassettes and LPs each need their own type of holders. Therefore, for the purpose of figuring out how much physical storage space you need for each type of object, the physical form of the object is indeed important. As always, the question is how you will use the information, not merely what information is available.

What about rare coins or stamps? If you had only a couple of either of these objects, you might very well use the “Basic” type to keep track of them. However, if you had an extensive collection, you probably would want to keep track of their condition, year of minting or printing, denomination and other data of interest to collectors. To handle this extra information, you would add a “Coin/Stamp” type or even two separate types, if you happened to collect both. This merely illustrates the rule that the handling of data has to be based on the use to which it will be put, not on its intrinsic characteristics alone.

Now that we've developed a general outline of these classes and the data that they need to keep track of, let's start designing the interface they will present to the application program that uses them.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset