The Elusive PERSON Class / Conrad Weisert

Many applications trying to exploit object-oriented
technology include Person objects among their central data
items. Indeed, a Person class is often used as an early
example in OOP courses and textbooks. But it's also one of
the most troublesome application-domain classes to get
right, and projects are littered with the incomplete and
inconsistent remains of flawed attempts.

Some disillusioned experts now claim that a non-trivial
general Person class supporting a full range of
applications is impossible and advise us not to bother
trying. "You can't define a Person class until you know
what the application is," was the serious warning put forth at a meeting last year!

Some of the questions that arise in designing a Person
class are:

• Should role-based classes, such as Student, Employee, Patient, or
Customer, be derived subclasses of Person? If not, how
should they be represented?

• Should the format and structure of persons' names be standardized? If so, how should we handle names from cultures outside Europe and America? How can we recognize duplicates?

• Can there be such a thing as a standard unique person identifier? Who controls and assigns them? Can we use a U.S. social security number?

• How should we represent deceased persons? fictional persons?

• How much transient information should be member data:

• mailing address?
• phone?
• height & weight?
• marital status?

How much history should be retained when those members change?

• What complications are raised by privacy considerations?

Person is an especially interesting example of a composite item class, because several of its member data items are themselves obvious candidates for O.O. classes. We shall examine some of them, too.

Conrad Weisert will offer his views on those and related issues, and will show C++ examples. This topic applies to Java and C# programming, too.

He last spoke to our group in February, 2012:

https://www.meetup.com/Chicago-C-CPP-Users-Group/events/49250862/