Class structure for an inventory control system

Question

As an exercise in good OO methods and design, I want to know what is a good way to model inventory control in a company. The problem description is

a. A company can have different types of items, like documents (both electronic and physical), computers etc which may further have their own sub types.

b. The items can be kept in a store, may be circulated to an employee, may be mailed out etc. An electronic document can be emailed to many people at a time.

c. Items may have certain restrictions like a classified document be circulated to only people/places with access (eg, people with classified clearance or a room cleared to store those documents etc)

what is a good class structure(s) that can be used to model this kind of tracking? (pseudo C# class structure or c++ would be helpful) and what kind of design patterns would be good for such a task

Answer 1

Answering your question would need deep investigation of the problem domain. I don't think there is a universally valid approach.

There are some patterns that are likely to appear, though. One of them (and one of the most difficult to implement, by the way), is the type/instance pattern. Based on my experience, I am assuming that the types of the items that your inventory app must keep track of cannot be fixed, and that users of your system must be able to create and modify types at any time. This means that your system needs to handle two levels of classification rather than the usual one; in other words, your system will have classes (in code), instances of those classes (in run-time) and instances of those instances (in run-time too).

For example, if you create the DocumentType class in code, your users would instantiate it a number of times, creating objects such as Report, Memo or Manual. Then, each individual report that your system manages would be an instance of Report. And each individual memo would be an instance of Memo. And so on.

This is easy to implement if subtypes (Report, Memo, Manual in my example) don't carry their own attributes or their own relationships to other pieces of information. However, if they need specific data structures (attributes and/or associations), then the problem becomes much harder, because you'll need to mimic a complete object-oriented type/instance engine within your system.

It's lots of fun, though!

Answer 2

Here's a preliminary suggestion to get you started:

struct Item
{
    // The requirements say everything is an item.
};

struct Document
: public Item
{
    // There are documents
};

struct Document_Physical
: public Document
{
    // Physical documents
};

struct Document_Electronic
: public Document
{
    // Electronic documents
};

struct Computer
: public Item
{
};

The contents of the items and their methods depends on the interpretation of the requirements document. This is one schema, there may be others.

Some useful design patterns: Visitor, Factory, Producer-Consumer to name a few. Also research the topic "refactoring".