|
ms
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Passing in different int context on same signature?signature. For example: Class1(int PersonId) {...} Class1(int EmployeeId) {...} Of course the above does not work because of the signatures. So I do a goofy work around: Class1(int EmployeeId, int forEmployeeId) {...} Where forEmployeeId gets any int value and is never processing. It's only there to distinguish the two constructors I need. I always have more Persons than Employees. A Person may not be an Employee but an Employee is always a Person. Is there a better way to do the above? My work around works fine but isn't very good. I know there is a more correct way of doing this and that's what I'd like to get at. I'd like to avoid switches and conditionals. I'm using .NET 2.0 so please pull out all of the stops if need be. Thanks, Brett
Show quote
Hide quote
On 11 Mar 2006 10:57:21 -0800, "Brett Romero" <acco***@cygen.com> wrote: If an employee is always a person then instead of using an employeeid, use a>I'd like to pass two different int contexts on the same constructor >signature. For example: > >Class1(int PersonId) >{...} > >Class1(int EmployeeId) >{...} > >Of course the above does not work because of the signatures. So I do a >goofy work around: > >Class1(int EmployeeId, int forEmployeeId) >{...} > >Where forEmployeeId gets any int value and is never processing. It's >only there to distinguish the two constructors I need. > >I always have more Persons than Employees. A Person may not be an >Employee but an Employee is always a Person. Is there a better way to >do the above? My work around works fine but isn't very good. I know >there is a more correct way of doing this and that's what I'd like to >get at. I'd like to avoid switches and conditionals. I'm using .NET >2.0 so please pull out all of the stops if need be. > >Thanks, >Brett PersonID and a bool property to indicate whether or not a person is an employee. Then you can do this with the constructor: Person(21, true); // person 21 is an employee and have an additional ctor: Person(21); // Default to not an employee, or is an employee (whichever meets your needs best). Otis Mukinfus http://www.arltex.com http://www.tomchilders.com I don't think it is any different than how I'm doing it now. Just that
you are using a bool where I'm using an int. Neither of the 2nd parameters will be processed. They are just providing different signatures. Brett On 11 Mar 2006 13:37:52 -0800, "Brett Romero" <acco***@cygen.com> wrote: If you are not processing the second parameter in your two parameter example how>I don't think it is any different than how I'm doing it now. Just that >you are using a bool where I'm using an int. Neither of the 2nd >parameters will be processed. They are just providing different >signatures. > >Brett will you tell upon retrieval if one of the objects you are creating is an employee or not? My vision of the solution was to have one ID and a method for determining after the fact that the object was or was not an employee. I'm confused by your logic there, unless you have another way to determine employee status upon retrieval. Otis Mukinfus http://www.arltex.com http://www.tomchilders.com Otis, you know it is a person if this constructor is used:
Class1(int personid) {...} You know it is an employee if this constructor is used: Class1(int employeeid, int justaflagforemployee){...} Brett On 11 Mar 2006 15:10:12 -0800, "Brett Romero" <acco***@cygen.com> wrote: Yes, I understand that part.>Otis, you know it is a person if this constructor is used: > >Class1(int personid) {...} > >You know it is an employee if this constructor is used: > >Class1(int employeeid, int justaflagforemployee){...} > >Brett Now that you have constructed the object and put it in a list or something and you go back to get it again, how will you know which constructor was used? Your second example is the same as using a bool. So you *are* processing the second parameter. That's not what you said earlier. Otis Mukinfus http://www.arltex.com http://www.tomchilders.com No, I'm not processing the second parameter. Here's what I do: When
the constructor with one parameter is used, I initialize everything regularly (have faith here). When the two parameter constructor is used, there is additional logic that will get me Person related information, including the PersonId, which I already have when the single parameter constructor is used. So, the two parameter constructor does everything the one parameter does and additional gathering of information (person information). By the time that is done, I'm in the same state as if some one had used the single parameter constructor, which is the ultimate state I want to be in. Brett Hello Otis,
I'd use interfaces for this. class takes base interface, IEmployee, and in class body cast this interface to the requires type or check with "is" keyword OM> On 11 Mar 2006 10:57:21 -0800, "Brett Romero" <acco***@cygen.com> OM> wrote:OM> Show quoteHide quote >> I'd like to pass two different int contexts on the same constructor OM> If an employee is always a person then instead of using an>> signature. For example: >> >> Class1(int PersonId) >> {...} >> Class1(int EmployeeId) >> {...} >> Of course the above does not work because of the signatures. So I do >> a goofy work around: >> >> Class1(int EmployeeId, int forEmployeeId) >> {...} >> Where forEmployeeId gets any int value and is never processing. It's >> only there to distinguish the two constructors I need. >> >> I always have more Persons than Employees. A Person may not be an >> Employee but an Employee is always a Person. Is there a better way >> to do the above? My work around works fine but isn't very good. I >> know there is a more correct way of doing this and that's what I'd >> like to get at. I'd like to avoid switches and conditionals. I'm >> using .NET 2.0 so please pull out all of the stops if need be. >> >> Thanks, >> Brett OM> employeeid, use a PersonID and a bool property to indicate whether OM> or not a person is an employee. Then you can do this with the OM> constructor: OM> OM> Person(21, true); // person 21 is an employee OM> and OM> have an additional ctor: OM> Person(21); // Default to not an employee, or is an employee OM> (whichever meets OM> your needs best). OM> Otis Mukinfus OM> http://www.arltex.com OM> http://www.tomchilders.com --- WBR, Michael Nemtsev :: blog: http://spaces.msn.com/laflour "At times one remains faithful to a cause only because its opponents do not cease to be insipid." (c) Friedrich Nietzsche On Sat, 11 Mar 2006 22:22:26 +0000 (UTC), Michael Nemtsev <nemt***@msn.com>
wrote: >Hello Otis, That is a more elegant way to do it Michael, and if a database were involved you> >I'd use interfaces for this. >class takes base interface, IEmployee, and in class body cast this interface >to the requires type or check with "is" keyword > could make both objects appear the same to the DB. I like it. However, upon retrieval from the DB you would still need a way to determine which type of object a row contained. It's like storing peoples names in a table. If you must know their sex, you have to have a way to tell if they are male or female. Typically that would be with a "sex" column. [snip] Otis Mukinfus http://www.arltex.com http://www.tomchilders.com  
Other interesting topics
Generic Dictionary performance?
Identify Interface in ArrayList of Intfaces Returning application name from hWnd handle. Returning application name from hWnd handle Specifying an interface-implemenation as parameter ComboBox like Address bar in IE or in Run Dialog box ComboBox doesn't have border when appearance is made flat in VS.NET 2005 System.Boolean Question. Many Classes Vs Many Methods in a single class Best value Help file builder |
|||||||||||||||||||||||
