OOP issue: should I pass an object or an object property?
in [CSharp]
|
Prev: Evetlog
Next: debugger class
From: Jeff Johnson on 6 May 2010 13:54 "csharper" <gnewsgroup(a)gmail.com> wrote in message news:34697467-9593-4ad4-a685-9fa2b349d478(a)r9g2000vbk.googlegroups.com... > Suppose now in another class, I need to use the employeeId in a method > GetContactInfo. 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.
From: Alberto Poblacion on 6 May 2010 14:16 "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.
From: Mr. Arnold on 6 May 2010 14:17 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.
From: joe on 6 May 2010 14:31 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. 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
From: Family Tree Mike on 6 May 2010 14:55
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. >> >> -- >> Mike > > 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. -- Mike |