OOP issue: should I pass an object or an object property?
in [CSharp]
|
Prev: Evetlog
Next: debugger class
From: Family Tree Mike on 6 May 2010 14:57 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. -- Mike
From: csharper on 6 May 2010 15:16 On May 6, 2:31 pm, joe <jgr...(a)doubletake.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. > > 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 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?
From: csharper on 6 May 2010 15:18 On May 6, 1:54 pm, "Jeff Johnson" <i....(a)enough.spam> wrote: > "csharper" <gnewsgr...(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. Yes, here is the presumption of my initial question: only the EmployeeId is needed for GetContactInfo method.
From: Mr. Arnold on 6 May 2010 15:35 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. > I don't know what the OP is doing, other than, the method needed an ID.
From: Jeff Johnson on 6 May 2010 16:05
"Family Tree Mike" <FamilyTreeMike(a)ThisOldHouse.com> wrote in message news:%23GWL13U7KHA.2240(a)TK2MSFTNGP06.phx.gbl... > He is getting the contact info from the Employee object, which I presume > is the FirstName, MiddleName, LastName properties. 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. |