Interfaces and Static methods - How could they!!!
-
Oh my lordy!!! How could they not allow static members in interfaces!!! That's soooo irritating. Tick, theres another todo on the C# wish list...
-
Oh my lordy!!! How could they not allow static members in interfaces!!! That's soooo irritating. Tick, theres another todo on the C# wish list...
Use an abstract class instead. An interface provides no implementation. Logically it doesnt make sense to add a static member to an interface, because at runtime the interface provides u with methods that can be used on an instance of an interface and never the interface directly. How about just adding it without making it static??? Seeing that it will be used with an instance of the interface. Maybe even move the static member to the class that implements the interface, although i would have no clue how to access it then. Again the keyword is instance. Hope this helps :) MYrc : A .NET IRC client with C# Plugin Capabilities. See http://sourceforge.net/projects/myrc for more info. :-D
-
Use an abstract class instead. An interface provides no implementation. Logically it doesnt make sense to add a static member to an interface, because at runtime the interface provides u with methods that can be used on an instance of an interface and never the interface directly. How about just adding it without making it static??? Seeing that it will be used with an instance of the interface. Maybe even move the static member to the class that implements the interface, although i would have no clue how to access it then. Again the keyword is instance. Hope this helps :) MYrc : A .NET IRC client with C# Plugin Capabilities. See http://sourceforge.net/projects/myrc for more info. :-D
What do you do leppie? You have amazing response times - not that I'm complaining. Anyways, I believe (not a language historian or anything) that is makes complete sense. For instance, lets say we have the following interface: IChalk { Color color { get; } void Break(); string SerializeXml(); static IChalk Deserialize( string Xml ); //Cannot actually do the static thang. } class GreenChalk : IChalk { Color IChalk.color { get { return Color.Red; } } void Break() { throw( new Exception("Damn it!!!") ); } string IChalk.SerializeXml() { XmlSerializer sr = new XmlSerializer( this.GetType ); //blah blah } static IChalk IChalk.Deserialize( string xml ){ GreenChalk gc = new GreenChalk(); //blah blah return gc; } } I hate using specific examples for explainations but it'll save on length and confusion. Now you could just make it deserialize to the instance and remove the need for the static member, but I believe it is more consistant this way; once you instanciate the implementing class you HAVE an IChalk, Deserialize in escence creates another one. So to Deserialize I have to create two versions. You do point out a good idea that could mirror that though. I could use an abstract class with the Serialization methods in them and do that I guess, but it is definitly a hack in my mind. Unless someone else (or you) can explain why it isn't.
-
What do you do leppie? You have amazing response times - not that I'm complaining. Anyways, I believe (not a language historian or anything) that is makes complete sense. For instance, lets say we have the following interface: IChalk { Color color { get; } void Break(); string SerializeXml(); static IChalk Deserialize( string Xml ); //Cannot actually do the static thang. } class GreenChalk : IChalk { Color IChalk.color { get { return Color.Red; } } void Break() { throw( new Exception("Damn it!!!") ); } string IChalk.SerializeXml() { XmlSerializer sr = new XmlSerializer( this.GetType ); //blah blah } static IChalk IChalk.Deserialize( string xml ){ GreenChalk gc = new GreenChalk(); //blah blah return gc; } } I hate using specific examples for explainations but it'll save on length and confusion. Now you could just make it deserialize to the instance and remove the need for the static member, but I believe it is more consistant this way; once you instanciate the implementing class you HAVE an IChalk, Deserialize in escence creates another one. So to Deserialize I have to create two versions. You do point out a good idea that could mirror that though. I could use an abstract class with the Serialization methods in them and do that I guess, but it is definitly a hack in my mind. Unless someone else (or you) can explain why it isn't.
static functions are generally a bad idea, it presumes how your class will be used. you are better off using a seperate help classer - see design patterns, GOF - "prefer composition to inheritance" (or something like that). Personally I think Serialization sucks - have a look a the memento pattern...
"When the only tool you have is a hammer, a sore thumb you will have."
-
What do you do leppie? You have amazing response times - not that I'm complaining. Anyways, I believe (not a language historian or anything) that is makes complete sense. For instance, lets say we have the following interface: IChalk { Color color { get; } void Break(); string SerializeXml(); static IChalk Deserialize( string Xml ); //Cannot actually do the static thang. } class GreenChalk : IChalk { Color IChalk.color { get { return Color.Red; } } void Break() { throw( new Exception("Damn it!!!") ); } string IChalk.SerializeXml() { XmlSerializer sr = new XmlSerializer( this.GetType ); //blah blah } static IChalk IChalk.Deserialize( string xml ){ GreenChalk gc = new GreenChalk(); //blah blah return gc; } } I hate using specific examples for explainations but it'll save on length and confusion. Now you could just make it deserialize to the instance and remove the need for the static member, but I believe it is more consistant this way; once you instanciate the implementing class you HAVE an IChalk, Deserialize in escence creates another one. So to Deserialize I have to create two versions. You do point out a good idea that could mirror that though. I could use an abstract class with the Serialization methods in them and do that I guess, but it is definitly a hack in my mind. Unless someone else (or you) can explain why it isn't.
Cromwell wrote: What do you do leppie? You have amazing response times - not that I'm complaining. I'm jobless hovering on a free GPRS connection :) Like in the post before mine, I would suggest making a helper class to take care of the static methods :) This could even be the abstract baseclass for all types of chalk, and the base class would implement IChalk. Else, cant static IChalk Deserialize( string Xml ) become non static, because adding a static member there does not make sense...:) MYrc : A .NET IRC client with C# Plugin Capabilities. See http://sourceforge.net/projects/myrc for more info. :-D
-
Cromwell wrote: What do you do leppie? You have amazing response times - not that I'm complaining. I'm jobless hovering on a free GPRS connection :) Like in the post before mine, I would suggest making a helper class to take care of the static methods :) This could even be the abstract baseclass for all types of chalk, and the base class would implement IChalk. Else, cant static IChalk Deserialize( string Xml ) become non static, because adding a static member there does not make sense...:) MYrc : A .NET IRC client with C# Plugin Capabilities. See http://sourceforge.net/projects/myrc for more info. :-D
leppie wrote: Else, cant static IChalk Deserialize( string Xml ) become non static, because adding a static member there does not make sense actually that was my argument. I think it doesn't make sense to not have it static. If it isn't static you have just instanciated two IChalk objects by returning an IChalk object. Also, as I mentioned, if you use the Deserialize as a member that updates/sets the values of the object. You have an invalid IChalk object between the point of instanciation and the Deserialization call. Granted it will be most common that the Deserialization call be made directly following the instanciate or, at least before the object is used, but a solid class wouldn't leave that moment of possibility open. Also, its possible that the deserialization method implemented by some other because they need the IChalk interface wouldn't do a good job of guaranteeing that the class is valid after deserialization. Ie deserialize may very well leave IChalk.color = null when that isn't acceptable because it wasn't specified in the serialized xml. Get my point. I see and realize there are ways of doing things (ie, abstract classes+interfaces, presume good implementation (;/), etc, but I'm a pain in the arse.
-
leppie wrote: Else, cant static IChalk Deserialize( string Xml ) become non static, because adding a static member there does not make sense actually that was my argument. I think it doesn't make sense to not have it static. If it isn't static you have just instanciated two IChalk objects by returning an IChalk object. Also, as I mentioned, if you use the Deserialize as a member that updates/sets the values of the object. You have an invalid IChalk object between the point of instanciation and the Deserialization call. Granted it will be most common that the Deserialization call be made directly following the instanciate or, at least before the object is used, but a solid class wouldn't leave that moment of possibility open. Also, its possible that the deserialization method implemented by some other because they need the IChalk interface wouldn't do a good job of guaranteeing that the class is valid after deserialization. Ie deserialize may very well leave IChalk.color = null when that isn't acceptable because it wasn't specified in the serialized xml. Get my point. I see and realize there are ways of doing things (ie, abstract classes+interfaces, presume good implementation (;/), etc, but I'm a pain in the arse.
Cromwell wrote: If it isn't static you have just instanciated two IChalk objects by returning an IChalk object. You would have to instanciated an IChalk object to use an IChalk object. Remember the type of the IChalk object will not be IChalk, it will be the actuall type of the class I think we should look back at the definition of an interface and if they really needed in your case. From what I can see, a base class with some abstract methods (those you would use with the original interface) will provided the best solution in your case and it would pretty much function the same. From MSDN: An interface: An interface defines a contract. A class or struct that implements an interface must adhere to its contract. An interface may inherit from multiple base interfaces, and a class or struct may implement multiple interfaces. Interfaces can contain methods, properties, events, and indexers. The interface itself does not provide implementations for the members that it defines. The interface merely specifies the members that must be supplied by classes or interfaces that implement the interface. An abstract class: When a non-abstract class is derived from an abstract class, the non-abstract class must include actual implementations of all inherited abstract members. Such implementations are provided by overriding the abstract members. MYrc : A .NET IRC client with C# Plugin Capabilities. See http://sourceforge.net/projects/myrc for more info. :-D
-
Cromwell wrote: If it isn't static you have just instanciated two IChalk objects by returning an IChalk object. You would have to instanciated an IChalk object to use an IChalk object. Remember the type of the IChalk object will not be IChalk, it will be the actuall type of the class I think we should look back at the definition of an interface and if they really needed in your case. From what I can see, a base class with some abstract methods (those you would use with the original interface) will provided the best solution in your case and it would pretty much function the same. From MSDN: An interface: An interface defines a contract. A class or struct that implements an interface must adhere to its contract. An interface may inherit from multiple base interfaces, and a class or struct may implement multiple interfaces. Interfaces can contain methods, properties, events, and indexers. The interface itself does not provide implementations for the members that it defines. The interface merely specifies the members that must be supplied by classes or interfaces that implement the interface. An abstract class: When a non-abstract class is derived from an abstract class, the non-abstract class must include actual implementations of all inherited abstract members. Such implementations are provided by overriding the abstract members. MYrc : A .NET IRC client with C# Plugin Capabilities. See http://sourceforge.net/projects/myrc for more info. :-D
leppie wrote: You would have to instanciated an IChalk object to use an IChalk object. Remember the type of the IChalk object will not be IChalk, it will be the actuall type of the class His point (and a good one) is that he shouldn't have needed to instantiate any object that implements IChalk in order to call Deserialize, by itself Deserialize doesn't need any state at all to operate (since it only creates a new instance of that object and returns a reference as the interface). I think the class factory pattern would apply well here, have a class/interface that deserializes and creates new instances of objects implementing IChalk.
interface IChalkFactory
{
IChalk Deserialize();
IChalk Create();
// etc
void Serialize(IChalk);
}James "And we are all men; apart from the females." - Colin Davies
-
leppie wrote: You would have to instanciated an IChalk object to use an IChalk object. Remember the type of the IChalk object will not be IChalk, it will be the actuall type of the class His point (and a good one) is that he shouldn't have needed to instantiate any object that implements IChalk in order to call Deserialize, by itself Deserialize doesn't need any state at all to operate (since it only creates a new instance of that object and returns a reference as the interface). I think the class factory pattern would apply well here, have a class/interface that deserializes and creates new instances of objects implementing IChalk.
interface IChalkFactory
{
IChalk Deserialize();
IChalk Create();
// etc
void Serialize(IChalk);
}James "And we are all men; apart from the females." - Colin Davies
Tanka! Maybe your explaination made more sense than mine did. I have to say the inability to add static members to an interface is quite irritating. Ugh... So many missing pieces...