OOP issue: should I pass an object or an object property?

  • Thread starter Thread starter csharper
  • Start date Start date
C

csharper

I have been wondering about this for a while. Suppose I have a class
Employee which has defined the following properties:

EmployeeId
FirstName
MiddleName
LastName
.... ...

Suppose now in another class, I need to use the employeeId in a method
GetContactInfo.

Now, should I pass an Employee object to GetContactInfo like below?

// Version 1.
public IEnumerable<ContactInfo> GetContactInfo(Employee employee)
{
// The implementation goes here.
}

Or should I simply pass the EmployeeId int like below?

// Version 2.
public IEnumerable<ContactInfo> GetContactInfo(int employeeId)
{
// The implementation goes here.
}

Both will work, but

Q1: From an OOP perspective, which is more OOP-like?
Q2: Which version has better performance? Version 1? Version 2? No
difference?

Thank you.
 
I have been wondering about this for a while. Suppose I have a class
Employee which has defined the following properties:

EmployeeId
FirstName
MiddleName
LastName
... ...

Suppose now in another class, I need to use the employeeId in a method
GetContactInfo.

Now, should I pass an Employee object to GetContactInfo like below?

// Version 1.
public IEnumerable<ContactInfo> GetContactInfo(Employee employee)
{
// The implementation goes here.
}

Or should I simply pass the EmployeeId int like below?

// Version 2.
public IEnumerable<ContactInfo> GetContactInfo(int employeeId)
{
// The implementation goes here.
}

Both will work, but

Q1: From an OOP perspective, which is more OOP-like?
Q2: Which version has better performance? Version 1? Version 2? No
difference?

Thank you.
Click to expand...

It would appear that version one is better performance wise, because in
version two you will need to find the employee information for the id,
hence requiring a search that version one does not need.

Version one is more OOP-like in that if employee and customer had
contact info, you could make the method accept the base of both.
 
csharper said:
I have been wondering about this for a while. Suppose I have a class
Employee which has defined the following properties:

EmployeeId
FirstName
MiddleName
LastName
... ...

Suppose now in another class, I need to use the employeeId in a method
GetContactInfo.

Now, should I pass an Employee object to GetContactInfo like below?

// Version 1.
public IEnumerable<ContactInfo> GetContactInfo(Employee employee)
{
// The implementation goes here.
}

Or should I simply pass the EmployeeId int like below?

// Version 2.
public IEnumerable<ContactInfo> GetContactInfo(int employeeId)
{
// The implementation goes here.
}

Both will work, but

Q1: From an OOP perspective, which is more OOP-like?
Q2: Which version has better performance? Version 1? Version 2? No
difference?

Thank you.
Click to expand...

You just pass the ID. You would pass the object if you needed to pass
the object to do more things with the object's properties or methods
within the method you have passed the object.

Speed considerations would be applied to you sending the object or a
single primitive type over the wire using WCF between a WCF client and
service as an example. Why send the whole object, if you're only working
with a single primitive type property within the object, which takes
time to transmit the object?
 
You just pass the ID. You would pass the object if you needed to pass
the object to do more things with the object's properties or methods
within the method you have passed the object.

Speed considerations would be applied to you sending the object or a
single primitive type over the wire using WCF between a WCF client and
service as an example. Why send the whole object, if you're only working
with a single primitive type property within the object, which takes
time to transmit the object?
Click to expand...

Let's say, in a standalone application, no network transmission is
involved. Are you suggesting that in this situation then there is no
difference btwn version 1 and version 2 in terms of performance?

Also, your opinion about whether we should pass an Employee object or
an employeeId int is opposite to that of Family Tree Mike, any
comments? Thanks.
 
It would appear that version one is better performance wise, because in
version two you will need to find the employee information for the id,
hence requiring a search that version one does not need.

Version one is more OOP-like in that if employee and customer had
contact info, you could make the method accept the base of both.
Click to expand...

Thanks for sharing. I understand that you say passing in the id would
require a search for that int, but passing in an Employee object would
also require a search for the EmployeeId integer inside the
GetContactInfo method. So, I don't see this as a valid argument with
regard to application level performance.
 
Suppose now in another class, I need to use the employeeId in a method
GetContactInfo.
Click to expand...

What do you need to use the EmployeeID for? Will you ONLY need that ID an
nothing else from an Employee object? Is so, pass only the ID. If you're
going to need to instantiate an Employee object from that ID then you might
as well pass the original Employee object in the first place.

In other words, without more information it's hard to say.
 
csharper said:
I have been wondering about this for a while. Suppose I have a class
Employee which has defined the following properties:

EmployeeId
FirstName
MiddleName
LastName
... ...

Suppose now in another class, I need to use the employeeId in a method
GetContactInfo.

Now, should I pass an Employee object to GetContactInfo like below?

// Version 1.
public IEnumerable<ContactInfo> GetContactInfo(Employee employee)
{
// The implementation goes here.
}

Or should I simply pass the EmployeeId int like below?

// Version 2.
public IEnumerable<ContactInfo> GetContactInfo(int employeeId)
{
// The implementation goes here.
}

Both will work, but

Q1: From an OOP perspective, which is more OOP-like?
Click to expand...

I have a third suggestion that you could use instead of options 1 and 2:
Place the GetContactInfo method INSIDE the Employee class. In that way you
would not have to pass any argument. You would simply invoke
result=theEmployee.GetContactInfo();
The GetContactInfo method would then fetch the Id as this.employeeId.

The reasoning from the OOP point of view is the following: A class is
supposed to hold data plus the methods that operate on that data.The
principles of encapsulation and abstraction require that the implementation
details be kept internal to the class. I presume that the EmployeeID, in
practice, is the primary key of a database table that stores the employees,
and it is a foreign key for the ContactDetails table. All of these are
implementation details, which should probably be kept internal to the class
that abstracts the Employee. So you don't want to be passing around the ID.
Let the Employee class know how to get its own contact details, and don't
expose outside of the class the specific key that is needed to get them.
 
csharper said:
Let's say, in a standalone application, no network transmission is
involved. Are you suggesting that in this situation then there is no
difference btwn version 1 and version 2 in terms of performance?
Click to expand...

Using the single primitive type in the method signature would be faster
than using the whole object I would think.
Also, your opinion about whether we should pass an Employee object or
an employeeId int is opposite to that of Family Tree Mike, any
comments? Thanks.
Click to expand...

If you're only using a single property out of the object, then why send
the entire object in the method?

You should understand the other aspects on the use of an object in oops,
because you're only touching a small aspect of using oops and objects.

An object can be like an independent individual little machine with
properties and methods that act upon the properties that can take care
of its own needs -- that's the power of the object.
 
csharper said:
I have been wondering about this for a while. Suppose I have a class
Employee which has defined the following properties:

EmployeeId
FirstName
MiddleName
LastName
... ...

Suppose now in another class, I need to use the employeeId in a method
GetContactInfo.

Now, should I pass an Employee object to GetContactInfo like below?

// Version 1.
public IEnumerable<ContactInfo> GetContactInfo(Employee employee)
{
// The implementation goes here.
}

Or should I simply pass the EmployeeId int like below?

// Version 2.
public IEnumerable<ContactInfo> GetContactInfo(int employeeId)
{
// The implementation goes here.
}

Both will work, but

Q1: From an OOP perspective, which is more OOP-like?
Q2: Which version has better performance? Version 1? Version 2? No
difference?

Thank you.
Click to expand...


In general, if there is no reason for GetContactInfo() to depend upon
Employee, you shouldn't introduce one. IOW version 2 should be
preferred unless there are strong reasons to the contrary. You can
write it anyway you want, but later on, when it is maintenance time, if
someone wants to modify Employee, they won't necessarily keep
GetContactInfo() in mind. It also allows GetContactInfo() to be used
with other classes that may contain the employee id. In general, it is
a good idea to avoid coupling if possible.

joe
 
Thanks for sharing. I understand that you say passing in the id would
require a search for that int, but passing in an Employee object would
also require a search for the EmployeeId integer inside the
GetContactInfo method. So, I don't see this as a valid argument with
regard to application level performance.
Click to expand...

Well, isn't that just as simple as employee.EmployeeID? I mean, it's
not a search.
 
Using the single primitive type in the method signature would be faster
than using the whole object I would think.

If you're only using a single property out of the object, then why send
the entire object in the method?

You should understand the other aspects on the use of an object in oops,
because you're only touching a small aspect of using oops and objects.

An object can be like an independent individual little machine with
properties and methods that act upon the properties that can take care
of its own needs -- that's the power of the object.
Click to expand...

He is getting the contact info from the Employee object, which I presume
is the FirstName, MiddleName, LastName properties.
 
In general, if there is no reason for GetContactInfo() to depend upon
Employee, you shouldn't introduce one.   IOW version 2 should be
preferred unless there are strong reasons to the contrary.  You can
write it anyway you want, but later on, when it is maintenance time, if
someone wants to modify Employee, they won't necessarily keep
GetContactInfo() in mind.  It also allows GetContactInfo() to be used
with other classes that may contain the employee id.  In general, it is
a good idea to avoid coupling if possible.

joe
Click to expand...

Yes, I agree, decoupling is the key. A lot of times, I only think of
decoupling from the database, which I have tried my best to decouple.
I haven't been aggressively pondering about and designing decoupled
objects. Although I think what you said make very good sense, we do
very often see methods which take an instance of classes, does this
mean many of these may not be well-designed?
 
What do you need to use the EmployeeID for? Will you ONLY need that ID an
nothing else from an Employee object? Is so, pass only the ID. If you're
going to need to instantiate an Employee object from that ID then you might
as well pass the original Employee object in the first place.

In other words, without more information it's hard to say.
Click to expand...

Yes, here is the presumption of my initial question: only the
EmployeeId is needed for GetContactInfo method.
 
Family said:
He is getting the contact info from the Employee object, which I presume
is the FirstName, MiddleName, LastName properties.
Click to expand...

I don't know what the OP is doing, other than, the method needed an ID.
 
He is getting the contact info from the Employee object, which I presume
is the FirstName, MiddleName, LastName properties.
Click to expand...

Thaty's what I assumed at first, but his reply to my question suggests that
that's not the case. It makes little sense given the name of the procedure,
but then perhaps the contact info that is being retrieved is, for example,
the employee's next of kin, which wouldn't be part of the Employee object
but would need the Employee ID to look that info up from the database.
 
Thaty's what I assumed at first, but his reply to my question suggests that
that's not the case. It makes little sense given the name of the procedure,
but then perhaps the contact info that is being retrieved is, for example,
the employee's next of kin, which wouldn't be part of the Employee object
but would need the Employee ID to look that info up from the database.
Click to expand...

I guess that is possible, but why cloud the issue by stating the
employee object contained the First, Middle and Last name properties?
 
I guess that is possible, but why cloud the issue by stating the employee
object contained the First, Middle and Last name properties?
Click to expand...

I'm with you, man. My first response was going to be exactly what yours was
until I saw Mr. Arnold's response and re-read cshapper's question carefully,
noting the part where he said "I need to use the employeeId in a method."
 
Family said:
I guess that is possible, but why cloud the issue by stating the
employee object contained the First, Middle and Last name properties?
Click to expand...

What else is an Employee object suppose to have in it but properties
pertaining to the employee? Contact can be another object related to the
Employee object, and Contact is linked to the Employee by EmployeeID.

But does that mean one must pass the Employee object into the method
that gets the Contact object by EemployeeID or just past the EmployeeID
(premative type) to method?

Some say yes and some say no. I say no and one doesn't need to pass the
Employee object in this case to be oops compliant.
 
What else is an Employee object suppose to have in it but properties
pertaining to the employee? Contact can be another object related to the
Employee object, and Contact is linked to the Employee by EmployeeID.
Click to expand...

In truth, though, "GetContactInfo" suggests to me that you're getting the
contact info ABOUT the employee, and this information should be available
directly from the Employee object. On the other hand, "GetContacts" gets the
employee's contacts, i.e., other people. But that's a matter of semantics
and could be argued either way.
 
Jeff said:
In truth, though, "GetContactInfo" suggests to me that you're getting the
contact info ABOUT the employee, and this information should be available
directly from the Employee object. On the other hand, "GetContacts" gets the
employee's contacts, i.e., other people. But that's a matter of semantics
and could be argued either way.
Click to expand...

Not necessarily should the info be directly available in Employee.
ContactID can be an property in Employee object, to lookup using a
method in the Contact object.

Contact is a different object, but that doesn't mean that Contact or
Contacts cannot be hosted and loaded in Employee as an object or List<T>
of objects within Employee, if one chose to do so.
 
Back
Top