addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1languagelaunch-new-window--smalllight-bulblinklocation-pinlockm-swarmSearchmailmessagesminusmobilemoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Chicago C/C++ Users Group Message Board › An unsolved OOP problem

An unsolved OOP problem

Conrad W.
Chicago, IL
Post #: 15
SIGOOT (Special interest group for object-oriented technology) was an independent Chicago organization in the 1990s. In addition to a monthly meeting with a featured speaker, it had a "study group" that met from time to time to discuss particular aspects of OOT. The organization drew 40-50 people to its monthly meetings when OOP was novel, but fizzled out when object-oriented technology had become the mainstream of software development.

One of the problems the study group tackled without ever resolving was the Person class. It may be an appropriate topic for one of our group's discussion and work sessions.

We've all seen class hierarchies in which various classes are derived from a root Person class. The derived classes may represent occupations (Employee, Manager, . . .) or activities (Customer, Student, Author, .. ), but they never work out satisfactorily. How can a program determine, for example, if a particular customer is also an employee? How can we even reliably compare two Person objects for equality? Do we need a universal identifier code? Should we distinguish between the Person (permanent) and the Role (temporary) a person may perform?

Even respected textbooks never seem to come up with a satisfactory solution to this long-standing OOP problem.

Yet we work on applications that NEED to manipulate such objects. Should we be satisfied with solutions that we know are inconsistent or faulty or should we work harder to try to settle the issue?

So, I have two questions:

1. Does any group member have a solution, complete or partial, to the Person class problem, and would he or she like to present it to the group?

2. Whether anyone does or doesn't, who's interested in a working-discussion group session (maybe a series of sessions) to work on the problem? We could start this month.
Bogdan K.
user 5708026
Palo Alto, CA
Post #: 1
1. I don't have the solution but the problem is interesting. I think Person should have a very minimal set of attributes and solve the problem of identity. First Name and Last Name is not enough to identify the person, there should be something else.

2. I'm interested in working on this problem. Seams like a good choice for group meeting.
A former member
Post #: 1
Barring any conflicts I'd be interesting in meeting to discuss this problem.
Bob Korbus
Nevin ":-)" L.
Libertyville, IL
Post #: 2
Question: what do you mean by OOP? Encapsulation? Inheritance? If the latter, I think there is a more fundamental question to ask: why do you believe that inheritance is a good model for this (or for value semantics in general)?

Admittedly, I've been swayed over the years by the arguments Sean Parent has made, and am currently reading Elements of Programming by Stepanov / McJones, and have the opinion that, while inheritance is a fine implementation technique, it rarely belongs in the interface. (Oh, I know this is not without controversy. :-)) Good design is based upon loose coupling and high cohesion, and inheritance is the opposite of that.

In C++, we have a much richer vocabulary than just OOP: there is generic programming, functional programming, collections (containers), etc.

If there are things that make it hard to determine equality, they probably don't belong in the Person class.

I really like the idea that concepts such as Employee, Customer, etc. are roles. I would model each role as collections of Persons (which container is dependent on the problem at hand), and those collections would be completely independent of the Person class itself. This allows for an indefinite number of different roles, and keeps the Person class structurally simple.

Or the short answer: I'd love to discuss this. :-)
James G.
Lake Zurich, IL
Post #: 6
This is something I call the IS-A trap. An employee is a person, so we need to express that in the design. This can lead to abstractions that don't work so well. One of the famous ones is that square is a rectangle. So, Square should inherit from Rectangle. How should a Square respond to changeAspectRatio()?

I doubt there is a general solution, because different applications have different needs from their Person objects. If we have a good decent idea of the responsibilities or Person and Employee, etc we see if some sort of type hierarchy helps.
What responsibilities do you have in mind for your Person, Employee, etc?

Conrad W.
Chicago, IL
Post #: 16
1. I don't have the solution but the problem is interesting. I think Person should have a very minimal set of attributes and solve the problem of identity. First Name and Last Name is not enough to identify the person, there should be something else.

In fact full name, gender, date of birth, and place of birth are still not enough to guarantee unique identity. Yet people, especially Americans, are reluctant to be given an identifier code.
One approach we've used is to assign a temporary generated ID when the object is first entered into the system and replace it by Social Security Number if we ever get it. Obviously, that's not absolutely foolproof, either, and it complicates relational keys, but it can work in local domains such as a student roster or company employee list. I'm eager to discuss this more.

Nevin ":-)" L.
Libertyville, IL
Post #: 4
People aren't against identifier codes per se; rather, we are against linking databases together, because it is rarely done for our benefit. There is no need for me to have one identifier that links to me in all the databases in the world, and plenty of benefits to having different identifiers in different systems.

As for social security number: I would not use it as an ID, because it is a) not unique and b) next to impossible to verify that you got the correct number for a given individual.

About the only way to model this level of accuracy in any programming language is to generate a unique key for each individual, and use the other info (name, gender, date of birth, SSN, etc.) when you need to map that key with a person. That, of course, opens up another can of worms (for instance: how do you verify someone's identity, or what do you do when some of the information is incorrect?), but that is beyond the realm of C++.
A former member
Post #: 19
This is a great discussion! Hopefully we can address it at our next meeting.
user 8351063
Chicago, IL
Post #: 1
It doesn't seem possible to genralize the person class without actually creating an actual person. Even then it may not be possible. There are too many attributes and methods. Inheritance is a nightmare. If anything the person class clearly demonstrates there are limits to the usefullness of OOT.

We tend to think of a person as something useful for business applications, but there are chemical or biological implications too. Before you can bring anything from the realm of abstraction and possibility into something concrete and real, you must give it boundaries. Any aspect that is unbounded will be undefined and unrealized.

If you define a person as an actor playing a role. Define a base class that has only basic information and create derived classes for each role, sub-role, etc.

Marcin Z.
Bloomington, IN
Post #: 1
I can see two ways to handle "the Person problem" without inheritance. One is by composition, where every role is represented as a class that contains a Person. Of course, composition can be flattened, where an Employee and Manager, for example, do not contain a Person class as a member, but just include all the information necessary from a person. This works out best if every person has only one role, and all persons are a part of some hierarchy. Such solution may work very well with generic programming, where Person becomes a "concept." For example, using the rejected C++0x concept notation, a person could be:

concept Person<typename T> {
std::string name(T);
std::string address(T);

This also works without concept notation, just like concepts in STL. So, for every kind of person, including Employee and Manager, one would have to define the name and address functions appropriately. Of course, there are several problems with that. One is how to store persons. If they are all to be stored in one collection than one needs some "variant" type like boost.any or boost.variant. Otherwise, all persons must be stored in some structured collection, like a company. Having a structured collection leads to the problem of boilerplate code:­­

I think, though, that boost.variant is a pretty good solution, but it does take toll on compile times and can produce complicated error messages. And, there is run-time overhead, but it is there with inheritance and virtual methods as well.

Another solution is to use associations, and that works quite well when a person can assume more then one role. Associations are akin to relations in relational databases. I know of at least one paper that discusses implementation of associations (not in C++):


I think that the author has worked on a C++ implementation as well, but that does not seem to be published. I am also not aware of any library for associations in C++. I will contact the author of the above paper, and ask him if he has worked on associations in C++.

Can anybody think of other solutions to the problem than composition and associations?
Powered by mvnForum

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