Previously we looked at some examples of classes that might be appropriate for a library computer system. You should be able to recognise an important sub-grouping of these classes. Classes such as “Book” and “Member” are physical or concrete classes; they correspond to “real” things in the physical world. However, the classes “Loan” and “Return date” are different “types” of class. They do not correspond to real, physical entities at all. We will refer to classes of this sort as “conceptual” classes. Many student mistakenly use the term “abstract” here; this should be avoided because “abstract class” has a quite different meaning, which will be explained later.

Some components of a software system have both concrete and conceptual representation. Consider the “Book” class: The conceptual book “War and Peace” by Tolstoy exists independently of the paper and binding of a real physical book; indeed the conceptual book may be said to exist if the only text in existence was in a computer's memory. In other words, in a sense the book exists outside of its physical representation. At the same time, a lending library loans physical, not conceptual, books. They are real entities made of paper, with barcodes for scanning, and so on.

This is not purely an academic distinction. Large, complex systems (particularly object-oriented databases) may be impossible to implement unless this subtle distinction is understood. For example, if the library's system only represents physical books, it has to store all information about each book in each instance of the “book” class. But if the library has, say, ten copies of each book, then most of this information is duplicated in each object, which is a waste of memory and can cause data inconsistencies. This problem always arises when there is a distinction between physical and conceptual representations of the same thing, and when there are multiple, similar physical instances of the conceptual item.

This is not an issue on which the novice designer should lose sleep; the majority of systems can be designed correctly even if the issue is not understood. However, it will improve the depth of your understanding if you take the trouble to ensure that the sense of this section is understood.