addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

The troublesome Person class

From: Conrad W.
Sent on: Thursday, June 14, 2012 8:45 AM

Almost all of us have worked on applications in which we needed a Person class along with associated roles, such as Customer, Employee, or Student.   Since the earliest days of OOP programmers have been creating those classes, but many of them have serious flaws, as do the examples in many textbooks.

I'm starting to prepare material for a course in which students need to manipulate Person objects.  I have strong opinions, especially about what not to do, but I'm far from satisfied that I have a satisfactory solution.

I'd like to draw upon this group's collective wisdom and experience.  Can we get a constructive dialogue started on this topic?



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