OOP issue: should I pass an object or an object property?
in [CSharp]
|
Prev: Evetlog
Next: debugger class
From: Arne Vajhøj on 6 May 2010 20:11 On 06-05-2010 14:55, Family Tree Mike wrote: > On 5/6/2010 1:52 PM, csharper wrote: >> On May 6, 1:12 pm, Family Tree Mike<FamilyTreeM...(a)ThisOldHouse.com> >> wrote: >>> On 5/6/2010 11:50 AM, csharper wrote: >>>> 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. >>> >>> 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. >> >> 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. > > Well, isn't that just as simple as employee.EmployeeID? I mean, it's not > a search. Searching for contacts based on employee id is a search no matter if a ref to the employee object or just the employee id is passed. It would be different if the employee object actually contained refs to the contacts, but that does not seem to fit the description. Arne
From: Arne Vajhøj on 6 May 2010 20:13 On 06-05-2010 14:57, Family Tree Mike wrote: > On 5/6/2010 2:17 PM, Mr. Arnold wrote: >> csharper wrote: >>> On May 6, 1:27 pm, "Mr. Arnold" <Arn...(a)Arnold.com> wrote: >>>> csharper wrote: >>>>> 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. >>>> 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? >>> >>> 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? >> >> 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. >> >> 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. > > He is getting the contact info from the Employee object, which I presume > is the FirstName, MiddleName, LastName properties. Give that contact info usually means phone numbers, email addresses etc. and that the method does not return ContactInfo but IEnumerable<ContactInfo>, then I don't think that is the case. Arne
From: Arne Vajhøj on 6 May 2010 20:18 On 06-05-2010 11:50, csharper wrote: > 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? Assuming that the contact info are looked up outside the employee object then #2. > Q2: Which version has better performance? Version 1? Version 2? No > difference? No difference that has any significance. Arne
From: Arne Vajhøj on 6 May 2010 20:20 On 06-05-2010 14:16, Alberto Poblacion wrote: > "csharper" <gnewsgroup(a)gmail.com> wrote in message > news:34697467-9593-4ad4-a685-9fa2b349d478(a)r9g2000vbk.googlegroups.com... >> 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? > > 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. That suggestion *combined* with actually storing the contact info in the employee object make sense. Just adding the method but not have the data does not look good to me. Arne
From: Alberto Poblacion on 7 May 2010 01:39
"Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4be35ca9$0$281$14726298(a)news.sunsite.dk... > [...] >> 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. > [...] > That suggestion *combined* with actually storing the contact > info in the employee object make sense. > > Just adding the method but not have the data does not look good You may, or may not, store the contact data inside the Employee objet. The point I wanted to make when I made the suggestion was that such storing of the data would be an internal implementation detail, and it should be transparent to the callers of Employee.GetContactInfo(). The implementation details are kept hidden inside the class; the callers should not have to care about how the class operates internally. In fact, you could write a first version that fetched the data from the database every time the method was called, and if the performance happened to be unacceptable, you could then rewrite it so that the contact info was cached in memory. This change in implementation would be transparent to the callers; no part of the code that uses the Employee class would have to be rewritten due to this internal change in the class. |