OOP Inheritance

[RSH]

Being rather new to OOP constructs I have a question regarding inheritance.

What is the proper way to setup my classes in a Company/Employee
relationship.

I have a Company Object and a company has employees (one to many
relationship) and CompanyDeductions. The Employees have EmployeeDeductions.
Based on my limited knowledge I set my objects as follows:

Public Class Company

Private _CompanyID As String

Private _Employees As New ArrayList

Private _Deductions As New ArrayList

Public Property CompanyID() As String

Get

Return _CompanyID

End Get

Set(ByVal Value As String)

_CompanyID = Value

End Set

End Property

Public ReadOnly Property Employees() As ArrayList

Get

Return _Employees

End Get

End Property

Public Sub LoadEmployees()

' Database call to get employees

Dim oDR As SqlClient.SqlDataReader

Dim oEmployee As New employee(oDR("EmployeeID"))

_Employees.Add(oEmployee)

End Sub

Public Sub LoadCompanyDeductions()

' Database call to get employees

Dim oDR As SqlClient.SqlDataReader

Dim oCompanyDeduction As New CompanyDeduction(oDR("DeductionID"))

_Employees.Add(oCompanyDeduction)

End Sub

End Class

Public Class Employee

Inherits Company

Private _EmployeeID As String

Private _FirstName As String

Private _LastName As String

Private _Deductions As ArrayList

Public Sub New(ByVal EmployeeID As String)

_EmployeeID = EmployeeID

End Sub

Public ReadOnly Property EmployeeID() As String

Get

Return _EmployeeID

End Get

End Property

Public ReadOnly Property FirstName() As String

Get

Return _FirstName

End Get

End Property

Public ReadOnly Property LastName() As String

Get

Return _LastName

End Get

End Property

Public Sub LoadEmployeeDeductions()

' Database call to get employees

Dim oDR As SqlClient.SqlDataReader

Dim oEmployeeDeduction As New EmployeeDeduction(oDR("DeductionID"))

_Deductions.Add(oEmployeeDeduction)

End Sub

End Class

Public Class CompanyDeduction

Inherits Company

Private _DeductionID As String

Private _DeductionName As String

Public Sub New(ByVal DeductionID As String)

_DeductionID = DeductionID

End Sub

Public ReadOnly Property DeductionID() As String

Get

Return _DeductionID

End Get

End Property

Public ReadOnly Property DeductionName() As String

Get

Return _DeductionName

End Get

End Property

End Class

Public Class EmployeeDeduction

Inherits Employee

Private _DeductionID As String

Private _DeductionName As String

Public Sub New(ByVal DeductionID As String)

_DeductionID = DeductionID

End Sub

Public ReadOnly Property DeductionID() As String

Get

Return _DeductionID

End Get

End Property

Public ReadOnly Property DeductionName() As String

Get

Return _DeductionName

End Get

End Property

End Class



Is this a good strategy? Or how could I make it better 9or more industry
standard?



Thank you for your time.

Ron

 

[Guest]

Ron,

No, this is not a good strategy.

An employee is not a company. A deduction is not an employee. Inheritance
really doesn't come into play in this example.

Kerry Moorman

 

[RSH]

So I should just treat them all as individual objects and instantiate them
from with in the other objects?

 

[Cor Ligthert [MVP]]

RSH,

A company has a collection of 0 or more employee's

The empoyee's are a property for the company, but a class itself which can
inherit female and male employees.

Cor

 

[Rory Becker]

RSH,

A company has a collection of 0 or more employee's
Agreed


The empoyee's are a property for the company, but a class itself which
can inherit female and male employees.

I'd have said either...
....'Gender' is a property of 'Employee'
Or
....'Male' and 'Female' are classes which inherit from 'Employee'

I think though that the first option is better because a 'Gender' property
could be pulled back into an ancesstor class 'Person' which 'Employee' and
'Owner' and 'Manager' could all inherit from.

Just abnother 2c

 

[RSH]

Thanks that makes perfect sense.

What collection is best for storing objects in the scenerio you cite below?

 

[Herfried K. Wagner [MVP]]

Rory,

I'd have said either...
...'Gender' is a property of 'Employee'
Or
...'Male' and 'Female' are classes which inherit from 'Employee'

I think though that the first option is better because a 'Gender' property
could be pulled back into an ancesstor class 'Person' which 'Employee' and
'Owner' and 'Manager' could all inherit from.

I'd implement the role pattern instead of using subtyping for different
genders and positions.

Martin Fowler: Dealing With Roles
<URL:http://www.martinfowler.com/apsupp/roles.pdf>

 

[Tom Leylan]

I'll offer the opinion that it doesn't make perfect sense

Would temporary employees and full-time also be subclasses? Are there then
subclasses of FemaleTemporary and MaleTemporary? How about former employees
and retirees who still get pension checks, more subclasses? Does a company
class have another collection for Consultants?

So imagine the app has been written and you're entering a new employee... is
the code instantiating a new FemaleEmployee() or MaleEmployee() or does it
have to ask that question first? Have you ever seen an app ask the sex of
the individual first? Let's say you need to fetch a person out of the
database do you instantiate an employee by passing a social security number?
And what happens if that person is a consultant? Wouldn't the datatype of
the variable tend to be wrong? You'd have to know at the time the SSN was
keyed in which type of object you expected back when all the user wants is a
person's personnel record.

Food for thought...

 

[Cor Ligthert [MVP]]

Have you ever seen an app ask the sex of the individual first?

Plenty of, just visit internet for dating sites although I have plenty of
more samples, but they are of course all sex (can be medical) related..

Cor