addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgoogleimageimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruseryahoo

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:

Join or login to comment.

  • A former member
    A former member

    Conrad did a good job presenting. What if at the meeting we split up into smaller groups so we can come up with our own ideas of how the Person class should be, then a rep from each group could do a mini-presentation of their findings and conclusions. I think this could be a good idea for almost any topic.

    1 · November 20, 2013

    • bjackfly

      I like the idea and it's funny I was thinking about the same thing today. I have been thinking of doing a presentation in the future and was thinking that more interactive might be better and help the learning by being more collaborative in sharing ideas.

      1 · November 20, 2013

  • bjackfly

    It's been a while since our last informal C++ learning meetup session. If anyone is interested in learning more about C++ or has any questions. We can meet tomorrow at the DePaul Barnes and noble cafe on State and Jackson at 6pm. If there are enough people we can go get a meeting room in the library up stairs there and use the white boards. Also, if interested you can send me a friend request on facebook under the same user name, bjackfly. I'll change my meetup picture so you will know who to look for.

    November 19, 2013

    • Carilda A T.

      Is your facebook profile searchable? I looked for bjackfly and got no results.

      November 19, 2013

    • bjackfly

      Try searching for Bjack Fly

      November 19, 2013

  • John D.

    Within the context of a single application (or small set of related applications in a suite), every one of these questions has a local, optimal answer. The interesting questions aren't so much about how to code a broad-use class, but how to federate multiple, locally optimal versions of this. Let each application manage the aspects / composite pieces s they think are relevant, but only where they are authoritative, and reference the rest. It seems more appropriate to have an SOA-style discussion about how to best solve this class problem across multiple (necessarily opaque) applications.

    Looking forward to the talk..

    November 14, 2013

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy