Article Preview
Buy Now
| Print: | |
| PDF: |
Object-Oriented Thinking
Is an Employee a Person?
Subclassing an employee class
Issue: 1.5 (April/May 2003)
Author: Charles Yeomans
Author Bio: Charles Yeomans is a software developer in Lexington, Kentucky.
Article Description: No description available.
Article Length (in bytes): 4,444
Starting Page Number: 36
RBD Number: 1518
Resource File(s): None
Related Link(s): None
Known Limitations: None
Excerpt of article text...
You're writing a small business accounting application, so of course you'll want to add an employee class. And, since the majority of businesses only employ people, class Employee should inherit from class Person. But what happens when this person leaves the employ of the company using your software, and returns as a consultant?
I've encountered this very problem in some well-known Macintosh accounting applications. What happens is that your user will be forced to re-enter the person's information to reincarnate him as a consultant.
One alternative to subclassing would be to define Employee and Vendor interfaces, and have Person implement both interfaces. But this doesn't feel right; the result is to turn the Person class into a union of the Employee and Vendor. If we consider this solution from the database end, it's clear that there will be a lot of wasted space as fields go unused for the majority of people who are not vendors.
What feels right is a design in which Person, Employee, and Vendor are distinct classes, unrelated by inheritance. In such a design, Person will be related to Employee and to Vendor by "uses" relationships, and Employee and Vendor are unrelated.
...End of Excerpt. Please purchase the magazine to read the full article.
Article copyrighted by REALbasic Developer magazine. All rights reserved.
|
