|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Class ConstructorsI have a class which defines multiple overloaded constructors. Within the
class methods is there a elegant way to determine which constructor was used to instantiate the class (without setting flags in the constructor)? Samudra wrote:
> I have a class which defines multiple overloaded constructors. Within the It shouldn't matter. All the constructors should leave the object in a> class methods is there a elegant way to determine which constructor was used > to instantiate the class (without setting flags in the constructor)? valid state to do whatever it needs to do. If you really need to do this, it's either bad design or ... well, I don't know. Show us some code? -- Larry Lard Replies to group please "Samudra" <Samu***@discussions.microsoft.com> wrote in message The fact that you care which constructor is called probably indicates a news:9177168F-3477-420D-8BB1-67A2FDFB4C6A@microsoft.com... >I have a class which defines multiple overloaded constructors. Within the > class methods is there a elegant way to determine which constructor was > used > to instantiate the class (without setting flags in the constructor)? design problem. After each constructor is run the object should be in its initial working state, and there should normally be no way to tell, or reason to care what constructor was used. David Samudra wrote:
> I have a class which defines multiple overloaded constructors. Within the In general, no. The behaviour of a class should be influenced by it's> class methods is there a elegant way to determine which constructor was used > to instantiate the class (without setting flags in the constructor)? functions, it's properties, and arguments passed to it's constructors or functions. Not as a side effect of how the object was constructed. If you need it's behaviour to be different, then make that explicit by exposing an argument to the constructor, to ask for this different behaviour. About the only way your request might make sense is if there are a mixture of private and public constructors, and you need different behaviour if one of you're private constructors has been called. About the only thing to do in this case would be to set a flag (which you've stated a preference away from). The simple reason for this? The vast majority of people do not want or need to know which constructor was used. If this information was to be automatically available, it would incur additional overhead for everyone using the framework who does not need this information. It's the same reason, for instance, that you cannot easily find out when an object was constructed - unless you explicitly store that information yourself within the constructor. Damien I concurr with the others.
I actually try to use 1 "main" constructor, and pass default values to it.. via other constructors. (see below) If you're tracking which contructor is called, you're doing something fudgy. An object is supposed to exist on its own. public class Emp { private string m_fname; private string m_lname; private bool m_isNew = true; //to show that the default falses work public Emp () : this("defaultFirst","defaultLast",false) { } public Emp (string fName, string lName, bool isNew) { this.m_fname = fName; this.m_lname = lName; this.m_isNew = isNew; } //then... if I have a constructor that doesnt have "isNew".. I do it like this public Emp (string fName, string lName) : this (fName,lName,false) { } public void ReportVariables() { string x = this.m_fname.ToString() + System.Environment.NewLine; x += this.m_lname.ToString() + System.Environment.NewLine; x += this.m_isNew .ToString() + System.Environment.NewLine; Console.WriteLine(x); } } // How To Use Emp e1 = new Emp(); e1.ReportVariables(); Emp e2 = new Emp("john" , "smith"); e2.ReportVariables(); Emp e3 = new Emp("mary", "jones", true); e3.ReportVariables(); Show quote "Samudra" <Samu***@discussions.microsoft.com> wrote in message news:9177168F-3477-420D-8BB1-67A2FDFB4C6A@microsoft.com... > I have a class which defines multiple overloaded constructors. Within the > class methods is there a elegant way to determine which constructor was used > to instantiate the class (without setting flags in the constructor)? Thanks for your inputs. What I am trying to do is quite simple. I have a
stongly typed collection class, which can be instantiated though different constructors - public MetaFieldCollection() {} public MetaFieldCollection(int elementID) {} public MetaFieldCollection (ElementType elemType) {} On first access, I lazy load the collection. Now, I also want to define a Refresh() Method, which will reload the collection. Of course, this means I need to know how the class was instantiated. One way I can do this is by checking whether elementID is set or elementType is set, which in itself is not an issue but I was wondering if there was a more direct mechanism - hence the question. I understand from Damien's reply why there is no direct mechanism. But would you guys say now also that the reason I need to know how my collection was instantiated is not justified and implies bad design? Show quote "Samudra" wrote: > I have a class which defines multiple overloaded constructors. Within the > class methods is there a elegant way to determine which constructor was used > to instantiate the class (without setting flags in the constructor)? Samudra <Samu***@discussions.microsoft.com> wrote:
Show quote > Thanks for your inputs. What I am trying to do is quite simple. I have a It sounds like you could do with a base class and two or three derived > stongly typed collection class, which can be instantiated though different > constructors - > > public MetaFieldCollection() > {} > public MetaFieldCollection(int elementID) > {} > public MetaFieldCollection (ElementType elemType) > {} > > On first access, I lazy load the collection. Now, I also want to define a > Refresh() Method, which will reload the collection. Of course, this means I > need to know how the class was instantiated. One way I can do this is by > checking whether elementID is set or elementType is set, which in itself is > not an issue but I was wondering if there was a more direct mechanism - hence > the question. > > I understand from Damien's reply why there is no direct mechanism. But would > you guys say now also that the reason I need to know how my collection was > instantiated is not justified and implies bad design? classes, each of which knew how to load their data in a different way. Currently, if someone instantiates the class using elemType, the elementID member is useless, and vice versa. That doesn't necessarily mean it's a bad design, but it's at least "smell" suggesting it's perhaps not quite right. -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too
Show quote
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message I agree with John but another alternative is to store a delegate to handle news:MPG.1ebc85046be5ef9198d179@msnews.microsoft.com... > Samudra <Samu***@discussions.microsoft.com> wrote: >> Thanks for your inputs. What I am trying to do is quite simple. I have a >> stongly typed collection class, which can be instantiated though >> different >> constructors - >> >> public MetaFieldCollection() >> {} >> public MetaFieldCollection(int elementID) >> {} >> public MetaFieldCollection (ElementType elemType) >> {} >> >> On first access, I lazy load the collection. Now, I also want to define a >> Refresh() Method, which will reload the collection. Of course, this means >> I >> need to know how the class was instantiated. One way I can do this is by >> checking whether elementID is set or elementType is set, which in itself >> is >> not an issue but I was wondering if there was a more direct mechanism - >> hence >> the question. >> >> I understand from Damien's reply why there is no direct mechanism. But >> would >> you guys say now also that the reason I need to know how my collection >> was >> instantiated is not justified and implies bad design? > > It sounds like you could do with a base class and two or three derived > classes, each of which knew how to load their data in a different way. > > Currently, if someone instantiates the class using elemType, the > elementID member is useless, and vice versa. That doesn't necessarily > mean it's a bad design, but it's at least "smell" suggesting it's > perhaps not quite right. Refresh. Nick Hounsome <N***@NickHounsome.Me.Uk> wrote:
> > Currently, if someone instantiates the class using elemType, the That has a *lot* of appeal - partly because you wouldn't actually need > > elementID member is useless, and vice versa. That doesn't necessarily > > mean it's a bad design, but it's at least "smell" suggesting it's > > perhaps not quite right. > > I agree with John but another alternative is to store a delegate to handle > Refresh. to keep hold of the elementId etc in the class itself, if you use an anonymous method which will capture the parameter value from the constructor. I like it :) -- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet If replying to the group, please do not mail me too  |
|||||||||||||||||||||||
Other interesting topics