This complete C# program illustrates the issue:
public abstract class Executor<T>
{
public abstract void Execute(T item);
}
class StringExecutor : Executor<string>
{
public void Execute(object item)
{
// why does this method call back into itself instead of binding
// to the more specific "string" overload.
this.Execute((string)item);
}
public override void Execute(string item) { }
}
class Program
{
static void Main(string[] args)
{
object item = "value";
new StringExecutor()
// stack overflow
.Execute(item);
}
}
I ran into a StackOverlowException that I traced back to this call pattern where I was trying to forward calls to a more specific overload. To my surprise, the invocation was not selecting the more specific overload however, but calling back into itself. It clearly has something to do with the base type being generic, but I don't understand why it wouldn't select the Execute(string) overload.
Does anyone have any insight into this?
The above code was simplified to show the pattern, the actual structure is a bit more complicated, but the issue is the same.
Looks like this is mentioned in the C# specification 5.0, 7.5.3 Overload Resolution:
Overload resolution selects the function member to invoke in the following distinct contexts within C#:
Invocation of a method named in an invocation-expression (§7.6.5.1).
Invocation of an instance constructor named in an object-creation-expression (§7.6.10.1).
Invocation of an indexer accessor through an element-access (§7.6.6).
Invocation of a predefined or user-defined operator referenced in an expression (§7.3.3 and §7.3.4).
Each of these contexts defines the set of candidate function members
and the list of arguments in its own unique way, as described in
detail in the sections listed above. For example, the set of
candidates for a method invocation does not include methods marked
override (§7.4), and methods in a base class are not candidates if any
method in a derived class is applicable (§7.6.5.1).
When we look at 7.4:
A member lookup of a name N with K type parameters in a type T is processed as follows:
• First, a set of accessible members named N is determined:
If T is a type parameter, then the set is the union of the sets of
accessible members named N in each of the types specified as a primary constraint or secondary constraint (§10.1.5) for T, along with the set of accessible members named N in object.
Otherwise, the set consists of all accessible (§3.5) members named N in T, including inherited members and the accessible membersnamed N in object. If T is a constructed type, the set of members
is obtained by substituting type arguments as described in §10.3.2.
Members that include an override modifier are excluded from the set.
If you remove override the compiler picks the Execute(string) overload when you cast the item.
As mentioned in Jon Skeet's article on overloading, when invoking a method in a class that also overrides a method with the same name from a base class, the compiler will always take the in-class method instead of the override, regardless of the "specificness" of type, provided that the signature is "compatible".
Jon goes on to point out that this is an excellent argument for avoiding overloading across inheritance boundaries, since this is exactly the kind of unexpected behavior that can occur.
As other answers have noted, this is by design.
Let's consider a less complicated example:
class Animal
{
public virtual void Eat(Apple a) { ... }
}
class Giraffe : Animal
{
public void Eat(Food f) { ... }
public override void Eat(Apple a) { ... }
}
The question is why giraffe.Eat(apple) resolves to Giraffe.Eat(Food) and not the virtual Animal.Eat(Apple).
This is a consequence of two rules:
(1) The type of the receiver is more important than the type of any argument when resolving overloads.
I hope it is clear why this must be the case. The person writing the derived class has strictly more knowledge than the person writing the base class, because the person writing the derived class used the base class, and not vice versa.
The person who wrote Giraffe said "I have a way for a Giraffe to eat any food" and that requires special knowledge of the internals of giraffe digestion. That information is not present in the base class implementation, which only knows how to eat apples.
So overload resolution should always prioritize choosing an applicable method of a derived class over choosing a method of a base class, regardless of the betterness of the argument type conversions.
(2) Choosing to override or not override a virtual method is not part of the public surface area of a class. That's a private implementation detail. Therefore no decision must be made when doing overload resolution that would change depending on whether or not a method is overridden.
Overload resolution must never say "I'm going to choose virtual Animal.Eat(Apple) because it was overridden".
Now, you might well say "OK, suppose I am inside Giraffe when I am making the call." Code inside Giraffe has all the knowledge of private implementation details, right? So it could make the decision to call virtual Animal.Eat(Apple) instead of Giraffe.Eat(Food) when faced with giraffe.Eat(apple), right? Because it knows that there is an implementation that understands the needs of giraffes that eat apples.
That's a cure worse than the disease. Now we have a situation where identical code has different behaviour depending on where it is run! You can imagine having a call to giraffe.Eat(apple) outside of the class, refactor it so that it is inside of the class, and suddenly observable behaviour changes!
Or, you might say, hey, I realize that my Giraffe logic is actually sufficiently general to move to a base class, but not to Animal, so I am going to refactor my Giraffe code to:
class Mammal : Animal
{
public void Eat(Food f) { ... }
public override void Eat(Apple a) { ... }
}
class Giraffe : Mammal
{
...
}
And now all calls to giraffe.Eat(apple) inside Giraffe suddenly have different overload resolution behaviour after the refactoring? That would be very unexpected!
C# is a pit-of-success language; we want very much to make sure that simple refactorings like changing where in a hierarchy a method is overridden do not cause subtle changes in behaviour.
Summing up:
Overload resolution prioritizes receivers over other arguments because calling specialized code that knows the internals of the receiver is better than calling more general code that does not.
Whether and where a method is overridden is not considered during overload resolution; all methods are treated as though they were never overridden for purposes of overload resolution. It's an implementation detail, not part of the surface of the type.
Overload resolution problems are solved -- modulo accessibility of course! -- the same way no matter where the problem occurs in the code. We do not have one algorithm for resolution where the receiver is of the type of the containing code, and another for when the call is in a different class.
Additional thoughts on related issues can be found here: https://ericlippert.com/2013/12/23/closer-is-better/ and here https://blogs.msdn.microsoft.com/ericlippert/2007/09/04/future-breaking-changes-part-three/
This complete C# program illustrates the issue:
public abstract class Executor<T>
{
public abstract void Execute(T item);
}
class StringExecutor : Executor<string>
{
public void Execute(object item)
{
// why does this method call back into itself instead of binding
// to the more specific "string" overload.
this.Execute((string)item);
}
public override void Execute(string item) { }
}
class Program
{
static void Main(string[] args)
{
object item = "value";
new StringExecutor()
// stack overflow
.Execute(item);
}
}
I ran into a StackOverlowException that I traced back to this call pattern where I was trying to forward calls to a more specific overload. To my surprise, the invocation was not selecting the more specific overload however, but calling back into itself. It clearly has something to do with the base type being generic, but I don't understand why it wouldn't select the Execute(string) overload.
Does anyone have any insight into this?
The above code was simplified to show the pattern, the actual structure is a bit more complicated, but the issue is the same.
Looks like this is mentioned in the C# specification 5.0, 7.5.3 Overload Resolution:
Overload resolution selects the function member to invoke in the following distinct contexts within C#:
Invocation of a method named in an invocation-expression (§7.6.5.1).
Invocation of an instance constructor named in an object-creation-expression (§7.6.10.1).
Invocation of an indexer accessor through an element-access (§7.6.6).
Invocation of a predefined or user-defined operator referenced in an expression (§7.3.3 and §7.3.4).
Each of these contexts defines the set of candidate function members
and the list of arguments in its own unique way, as described in
detail in the sections listed above. For example, the set of
candidates for a method invocation does not include methods marked
override (§7.4), and methods in a base class are not candidates if any
method in a derived class is applicable (§7.6.5.1).
When we look at 7.4:
A member lookup of a name N with K type parameters in a type T is processed as follows:
• First, a set of accessible members named N is determined:
If T is a type parameter, then the set is the union of the sets of
accessible members named N in each of the types specified as a primary constraint or secondary constraint (§10.1.5) for T, along with the set of accessible members named N in object.
Otherwise, the set consists of all accessible (§3.5) members named N in T, including inherited members and the accessible membersnamed N in object. If T is a constructed type, the set of members
is obtained by substituting type arguments as described in §10.3.2.
Members that include an override modifier are excluded from the set.
If you remove override the compiler picks the Execute(string) overload when you cast the item.
As mentioned in Jon Skeet's article on overloading, when invoking a method in a class that also overrides a method with the same name from a base class, the compiler will always take the in-class method instead of the override, regardless of the "specificness" of type, provided that the signature is "compatible".
Jon goes on to point out that this is an excellent argument for avoiding overloading across inheritance boundaries, since this is exactly the kind of unexpected behavior that can occur.
As other answers have noted, this is by design.
Let's consider a less complicated example:
class Animal
{
public virtual void Eat(Apple a) { ... }
}
class Giraffe : Animal
{
public void Eat(Food f) { ... }
public override void Eat(Apple a) { ... }
}
The question is why giraffe.Eat(apple) resolves to Giraffe.Eat(Food) and not the virtual Animal.Eat(Apple).
This is a consequence of two rules:
(1) The type of the receiver is more important than the type of any argument when resolving overloads.
I hope it is clear why this must be the case. The person writing the derived class has strictly more knowledge than the person writing the base class, because the person writing the derived class used the base class, and not vice versa.
The person who wrote Giraffe said "I have a way for a Giraffe to eat any food" and that requires special knowledge of the internals of giraffe digestion. That information is not present in the base class implementation, which only knows how to eat apples.
So overload resolution should always prioritize choosing an applicable method of a derived class over choosing a method of a base class, regardless of the betterness of the argument type conversions.
(2) Choosing to override or not override a virtual method is not part of the public surface area of a class. That's a private implementation detail. Therefore no decision must be made when doing overload resolution that would change depending on whether or not a method is overridden.
Overload resolution must never say "I'm going to choose virtual Animal.Eat(Apple) because it was overridden".
Now, you might well say "OK, suppose I am inside Giraffe when I am making the call." Code inside Giraffe has all the knowledge of private implementation details, right? So it could make the decision to call virtual Animal.Eat(Apple) instead of Giraffe.Eat(Food) when faced with giraffe.Eat(apple), right? Because it knows that there is an implementation that understands the needs of giraffes that eat apples.
That's a cure worse than the disease. Now we have a situation where identical code has different behaviour depending on where it is run! You can imagine having a call to giraffe.Eat(apple) outside of the class, refactor it so that it is inside of the class, and suddenly observable behaviour changes!
Or, you might say, hey, I realize that my Giraffe logic is actually sufficiently general to move to a base class, but not to Animal, so I am going to refactor my Giraffe code to:
class Mammal : Animal
{
public void Eat(Food f) { ... }
public override void Eat(Apple a) { ... }
}
class Giraffe : Mammal
{
...
}
And now all calls to giraffe.Eat(apple) inside Giraffe suddenly have different overload resolution behaviour after the refactoring? That would be very unexpected!
C# is a pit-of-success language; we want very much to make sure that simple refactorings like changing where in a hierarchy a method is overridden do not cause subtle changes in behaviour.
Summing up:
Overload resolution prioritizes receivers over other arguments because calling specialized code that knows the internals of the receiver is better than calling more general code that does not.
Whether and where a method is overridden is not considered during overload resolution; all methods are treated as though they were never overridden for purposes of overload resolution. It's an implementation detail, not part of the surface of the type.
Overload resolution problems are solved -- modulo accessibility of course! -- the same way no matter where the problem occurs in the code. We do not have one algorithm for resolution where the receiver is of the type of the containing code, and another for when the call is in a different class.
Additional thoughts on related issues can be found here: https://ericlippert.com/2013/12/23/closer-is-better/ and here https://blogs.msdn.microsoft.com/ericlippert/2007/09/04/future-breaking-changes-part-three/
It seems a very simple question, but clearly I'm missing something.
I did a test:
class A
{
public override int GetHashCode()
{
Console.WriteLine(base.GetType().Name);
return 0;
}
}
I was expecting to find 'object' but I find 'A'.
I was relying on this behaviour to invoke the base GetHashCode is particular cases withing an implementation, calling base.GetHashCode() and I was expecting the object implementation to be invoked.
What's wrong?
base. notation changes method that is called for overridden virtual methods (like GetHashCode in your sample - base.GetHashCode() calls object.GetHashCode, this.GetHashCode() calls A.GetHashCode()). base. can also be used to hidden base class' method, but it is not the case in this sample.
Since GetType is not virtual and there is no hiding then calling this.GetType() and base.GetType() behaves identical and calls object.GetType which returns "The exact runtime type of the current instance" as specified in documentation
GetType() always returns the current type, even if called on base. To get the base type, you can do this:
class A
{
public override int GetHashCode()
{
Console.WriteLine(this.GetType().BaseType.Name);
return 0;
}
}
BTW base.GetHashCode() works as expected. If you call it within A it will execute the object implementation.
You are confusing two very different things here. One is what method implementation is called and the other is what the runtime type type of the object is.
object.GetType() is implemented in object and it will always return the runtime type of the instance it’s called upon.
Now, when you call method Foo from any given class that doesn’t implement Foo but rather inherits it from a base type (your case), base.Foo or Foo are essentially the same thing because the only existing Foo is base.Foo.
However, if the class implements it’s own Foo, bet it overriding a virtual method or hiding a non virtual method the method called will be different. Don’t get confused by the other answers stating that the behavior you are seeing is due to GetType not being virtual, that is not true.
class A { int Foo() => 1;}
class B { }
class C { new int Foo() => 2; }
Calling Foo or base.Foo from within B is the same, calling it from within C is not; the former will return 2 the latter 1.
Equalsk's comment and post (here for brevity) are what you need to know, but I'll go an extra step and tell you why you want it this way.
Given class A only inherits from System.Object,
And given class B and class C are subclasses of class A:
In class B or C, the base.GetType().Name will be A. You expected this because it's defined in the subclasses that they inherit from A.
In class A, you still get A. Why wouldn't you want object?
The answer is simple. Say I write a method like this one:
public static void DoStuff(A input)
{
}
I can send DoStuff(input) with input being classes A, B, or C. This is because their base type is A. This is desirable. We wouldn't want to implicitly (and confusingly) exclude class A from a method that takes its derivatives; if we did, we'd want A to be an uninstantiable interface.
Think of System.Object as an ancestor. If someone asks you where you came from, you don't respond "Evolution in Mesopotamia", you typically would just address the lineage relevant to your existence. The object class is essentially primordial ooze, so you won't reference it unless you're trying to tell something it should accept anything it's passed as a parameter, or are unsure what object type you'll deal with.
An example of that last case is this:
public void DoStuffAgain(object x)
{
Messagebox.Show(x.GetType().Name);
}
In theory, everything coming down the pipe would be object. Instead, you might pass this your "A" class, and you'd want to know "A" because that's what you passed it. This is true even though x is of type object.
BaseType (a property) will return your base for a class, as stated in other answers. This won't lead you to object, though, unless the class doesn't explicitly inherit from something else.
Why was C# designed this way?
As I understand it, an interface only describes behaviour, and serves the purpose of describing a contractual obligation for classes implementing the interface that certain behaviour is implemented.
If classes wish to implement that behavour in a shared method, why shouldn't they?
Here is an example of what I have in mind:
// These items will be displayed in a list on the screen.
public interface IListItem {
string ScreenName();
...
}
public class Animal: IListItem {
// All animals will be called "Animal".
public static string ScreenName() {
return "Animal";
}
....
}
public class Person: IListItem {
private string name;
// All persons will be called by their individual names.
public string ScreenName() {
return name;
}
....
}
Assuming you are asking why you can't do this:
public interface IFoo {
void Bar();
}
public class Foo: IFoo {
public static void Bar() {}
}
This doesn't make sense to me, semantically. Methods specified on an interface should be there to specify the contract for interacting with an object. Static methods do not allow you to interact with an object - if you find yourself in the position where your implementation could be made static, you may need to ask yourself if that method really belongs in the interface.
To implement your example, I would give Animal a const property, which would still allow it to be accessed from a static context, and return that value in the implementation.
public class Animal: IListItem {
/* Can be tough to come up with a different, yet meaningful name!
* A different casing convention, like Java has, would help here.
*/
public const string AnimalScreenName = "Animal";
public string ScreenName(){ return AnimalScreenName; }
}
For a more complicated situation, you could always declare another static method and delegate to that. In trying come up with an example, I couldn't think of any reason you would do something non-trivial in both a static and instance context, so I'll spare you a FooBar blob, and take it as an indication that it might not be a good idea.
My (simplified) technical reason is that static methods are not in the vtable, and the call site is chosen at compile time. It's the same reason you can't have override or virtual static members. For more details, you'd need a CS grad or compiler wonk - of which I'm neither.
For the political reason, I'll quote Eric Lippert (who is a compiler wonk, and holds a Bachelor of Mathematics, Computer science and Applied Mathematics from University of Waterloo (source: LinkedIn):
...the core design principle of static methods, the principle that gives them their name...[is]...it can always be determined exactly, at compile time, what method will be called. That is, the method can be resolved solely by static analysis of the code.
Note that Lippert does leave room for a so-called type method:
That is, a method associated with a type (like a static), which does not take a non-nullable “this” argument (unlike an instance or virtual), but one where the method called would depend on the constructed type of T (unlike a static, which must be determinable at compile time).
but is yet to be convinced of its usefulness.
Most answers here seem to miss the whole point. Polymorphism can be used not only between instances, but also between types. This is often needed, when we use generics.
Suppose we have type parameter in generic method and we need to do some operation with it. We dont want to instantinate, because we are unaware of the constructors.
For example:
Repository GetRepository<T>()
{
//need to call T.IsQueryable, but can't!!!
//need to call T.RowCount
//need to call T.DoSomeStaticMath(int param)
}
...
var r = GetRepository<Customer>()
Unfortunately, I can come up only with "ugly" alternatives:
Use reflection
Ugly and beats the idea of interfaces and polymorphism.
Create completely separate factory class
This might greatly increase the complexity of the code. For example, if we are trying to model domain objects, each object would need another repository class.
Instantiate and then call the desired interface method
This can be hard to implement even if we control the source for the classes, used as generic parameters. The reason is that, for example we might need the instances to be only in well-known, "connected to DB" state.
Example:
public class Customer
{
//create new customer
public Customer(Transaction t) { ... }
//open existing customer
public Customer(Transaction t, int id) { ... }
void SomeOtherMethod()
{
//do work...
}
}
in order to use instantination for solving the static interface problem we need to do the following thing:
public class Customer: IDoSomeStaticMath
{
//create new customer
public Customer(Transaction t) { ... }
//open existing customer
public Customer(Transaction t, int id) { ... }
//dummy instance
public Customer() { IsDummy = true; }
int DoSomeStaticMath(int a) { }
void SomeOtherMethod()
{
if(!IsDummy)
{
//do work...
}
}
}
This is obviously ugly and also unnecessary complicates the code for all other methods. Obviously, not an elegant solution either!
I know it's an old question, but it's interesting. The example isn't the best. I think it would be much clearer if you showed a usage case:
string DoSomething<T>() where T:ISomeFunction
{
if (T.someFunction())
...
}
Merely being able to have static methods implement an interface would not achieve what you want; what would be needed would be to have static members as part of an interface. I can certainly imagine many usage cases for that, especially when it comes to being able to create things. Two approaches I could offer which might be helpful:
Create a static generic class whose type parameter will be the type you'd be passing to DoSomething above. Each variation of this class will have one or more static members holding stuff related to that type. This information could supplied either by having each class of interest call a "register information" routine, or by using Reflection to get the information when the class variation's static constructor is run. I believe the latter approach is used by things like Comparer<T>.Default().
For each class T of interest, define a class or struct which implements IGetWhateverClassInfo<T> and satisfies a "new" constraint. The class won't actually contain any fields, but will have a static property which returns a static field with the type information. Pass the type of that class or struct to the generic routine in question, which will be able to create an instance and use it to get information about the other class. If you use a class for this purpose, you should probably define a static generic class as indicated above, to avoid having to construct a new descriptor-object instance each time. If you use a struct, instantiation cost should be nil, but every different struct type would require a different expansion of the DoSomething routine.
None of these approaches is really appealing. On the other hand, I would expect that if the mechanisms existed in CLR to provide this sort of functionality cleanly, .net would allow one to specify parameterized "new" constraints (since knowing if a class has a constructor with a particular signature would seem to be comparable in difficulty to knowing if it has a static method with a particular signature).
Short-sightedness, I'd guess.
When originally designed, interfaces were intended only to be used with instances of class
IMyInterface val = GetObjectImplementingIMyInterface();
val.SomeThingDefinedinInterface();
It was only with the introduction of interfaces as constraints for generics did adding a static method to an interface have a practical use.
(responding to comment:) I believe changing it now would require a change to the CLR, which would lead to incompatibilities with existing assemblies.
To the extent that interfaces represent "contracts", it seems quiet reasonable for static classes to implement interfaces.
The above arguments all seem to miss this point about contracts.
Interfaces specify behavior of an object.
Static methods do not specify a behavior of an object, but behavior that affects an object in some way.
Because the purpose of an interface is to allow polymorphism, being able to pass an instance of any number of defined classes that have all been defined to implement the defined interface... guaranteeing that within your polymorphic call, the code will be able to find the method you are calling. it makes no sense to allow a static method to implement the interface,
How would you call it??
public interface MyInterface { void MyMethod(); }
public class MyClass: MyInterface
{
public static void MyMethod() { //Do Something; }
}
// inside of some other class ...
// How would you call the method on the interface ???
MyClass.MyMethod(); // this calls the method normally
// not through the interface...
// This next fails you can't cast a classname to a different type...
// Only instances can be Cast to a different type...
MyInterface myItf = MyClass as MyInterface;
Actually, it does.
As of Mid-2022, the current version of C# has full support for so-called static abstract members:
interface INumber<T>
{
static abstract T Zero { get; }
}
struct Fraction : INumber<Fraction>
{
public static Fraction Zero { get; } = new Fraction();
public long Numerator;
public ulong Denominator;
....
}
Please note that depending on your version of Visual Studio and your installed .NET SDK, you'll either have to update at least one of them (or maybe both), or that you'll have to enable preview features (see Use preview features & preview language in Visual Studio).
See more:
https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/tutorials/static-virtual-interface-members
https://blog.ndepend.com/c-11-static-abstract-members/
https://khalidabuhakmeh.com/static-abstract-members-in-csharp-10-interfaces#:~:text=Static%20abstract%20members%20allow%20each,like%20any%20other%20interface%20definition.
Regarding static methods used in non-generic contexts I agree that it doesn't make much sense to allow them in interfaces, since you wouldn't be able to call them if you had a reference to the interface anyway. However there is a fundamental hole in the language design created by using interfaces NOT in a polymorphic context, but in a generic one. In this case the interface is not an interface at all but rather a constraint. Because C# has no concept of a constraint outside of an interface it is missing substantial functionality. Case in point:
T SumElements<T>(T initVal, T[] values)
{
foreach (var v in values)
{
initVal += v;
}
}
Here there is no polymorphism, the generic uses the actual type of the object and calls the += operator, but this fails since it can't say for sure that that operator exists. The simple solution is to specify it in the constraint; the simple solution is impossible because operators are static and static methods can't be in an interface and (here is the problem) constraints are represented as interfaces.
What C# needs is a real constraint type, all interfaces would also be constraints, but not all constraints would be interfaces then you could do this:
constraint CHasPlusEquals
{
static CHasPlusEquals operator + (CHasPlusEquals a, CHasPlusEquals b);
}
T SumElements<T>(T initVal, T[] values) where T : CHasPlusEquals
{
foreach (var v in values)
{
initVal += v;
}
}
There has been lots of talk already about making an IArithmetic for all numeric types to implement, but there is concern about efficiency, since a constraint is not a polymorphic construct, making a CArithmetic constraint would solve that problem.
Because interfaces are in inheritance structure, and static methods don't inherit well.
What you seem to want would allow for a static method to be called via both the Type or any instance of that type. This would at very least result in ambiguity which is not a desirable trait.
There would be endless debates about whether it mattered, which is best practice and whether there are performance issues doing it one way or another. By simply not supporting it C# saves us having to worry about it.
Its also likely that a compilier that conformed to this desire would lose some optimisations that may come with a more strict separation between instance and static methods.
You can think of the static methods and non-static methods of a class as being different interfaces. When called, static methods resolve to the singleton static class object, and non-static methods resolve to the instance of the class you deal with. So, if you use static and non-static methods in an interface, you'd effectively be declaring two interfaces when really we want interfaces to be used to access one cohesive thing.
To give an example where I am missing either static implementation of interface methods or what Mark Brackett introduced as the "so-called type method":
When reading from a database storage, we have a generic DataTable class that handles reading from a table of any structure. All table specific information is put in one class per table that also holds data for one row from the DB and which must implement an IDataRow interface. Included in the IDataRow is a description of the structure of the table to read from the database. The DataTable must ask for the datastructure from the IDataRow before reading from the DB. Currently this looks like:
interface IDataRow {
string GetDataSTructre(); // How to read data from the DB
void Read(IDBDataRow); // How to populate this datarow from DB data
}
public class DataTable<T> : List<T> where T : IDataRow {
public string GetDataStructure()
// Desired: Static or Type method:
// return (T.GetDataStructure());
// Required: Instantiate a new class:
return (new T().GetDataStructure());
}
}
The GetDataStructure is only required once for each table to read, the overhead for instantiating one more instance is minimal. However, it would be nice in this case here.
FYI: You could get a similar behavior to what you want by creating extension methods for the interface. The extension method would be a shared, non overridable static behavior. However, unfortunately, this static method would not be part of the contract.
Interfaces are abstract sets of defined available functionality.
Whether or not a method in that interface behaves as static or not is an implementation detail that should be hidden behind the interface. It would be wrong to define an interface method as static because you would be unnecessarily forcing the method to be implemented in a certain way.
If methods were defined as static, the class implementing the interface wouldn't be as encapsulated as it could be. Encapsulation is a good thing to strive for in object oriented design (I won't go into why, you can read that here: http://en.wikipedia.org/wiki/Object-oriented). For this reason, static methods aren't permitted in interfaces.
Static classes should be able to do this so they can be used generically. I had to instead implement a Singleton to achieve the desired results.
I had a bunch of Static Business Layer classes that implemented CRUD methods like "Create", "Read", "Update", "Delete" for each entity type like "User", "Team", ect.. Then I created a base control that had an abstract property for the Business Layer class that implemented the CRUD methods. This allowed me to automate the "Create", "Read", "Update", "Delete" operations from the base class. I had to use a Singleton because of the Static limitation.
Most people seem to forget that in OOP Classes are objects too, and so they have messages, which for some reason c# calls "static method".
The fact that differences exist between instance objects and class objects only shows flaws or shortcomings in the language.
Optimist about c# though...
OK here is an example of needing a 'type method'. I am creating one of a set of classes based on some source XML. So I have a
static public bool IsHandled(XElement xml)
function which is called in turn on each class.
The function should be static as otherwise we waste time creating inappropriate objects.
As #Ian Boyde points out it could be done in a factory class, but this just adds complexity.
It would be nice to add it to the interface to force class implementors to implement it. This would not cause significant overhead - it is only a compile/link time check and does not affect the vtable.
However, it would also be a fairly minor improvement. As the method is static, I as the caller, must call it explicitly and so get an immediate compile error if it is not implemented. Allowing it to be specified on the interface would mean this error comes marginally earlier in the development cycle, but this is trivial compared to other broken-interface issues.
So it is a minor potential feature which on balance is probably best left out.
The fact that a static class is implemented in C# by Microsoft creating a special instance of a class with the static elements is just an oddity of how static functionality is achieved. It is isn't a theoretical point.
An interface SHOULD be a descriptor of the class interface - or how it is interacted with, and that should include interactions that are static. The general definition of interface (from Meriam-Webster): the place or area at which different things meet and communicate with or affect each other. When you omit static components of a class or static classes entirely, we are ignoring large sections of how these bad boys interact.
Here is a very clear example of where being able to use interfaces with static classes would be quite useful:
public interface ICrudModel<T, Tk>
{
Boolean Create(T obj);
T Retrieve(Tk key);
Boolean Update(T obj);
Boolean Delete(T obj);
}
Currently, I write the static classes that contain these methods without any kind of checking to make sure that I haven't forgotten anything. Is like the bad old days of programming before OOP.
C# and the CLR should support static methods in interfaces as Java does. The static modifier is part of a contract definition and does have meaning, specifically that the behavior and return value do not vary base on instance although it may still vary from call to call.
That said, I recommend that when you want to use a static method in an interface and cannot, use an annotation instead. You will get the functionality you are looking for.
Static Methods within an Interface are allowed as of c# 9 (see https://www.dotnetcurry.com/csharp/simpler-code-with-csharp-9).
I think the short answer is "because it is of zero usefulness".
To call an interface method, you need an instance of the type. From instance methods you can call any static methods you want to.
I think the question is getting at the fact that C# needs another keyword, for precisely this sort of situation. You want a method whose return value depends only on the type on which it is called. You can't call it "static" if said type is unknown. But once the type becomes known, it will become static. "Unresolved static" is the idea -- it's not static yet, but once we know the receiving type, it will be. This is a perfectly good concept, which is why programmers keep asking for it. But it didn't quite fit into the way the designers thought about the language.
Since it's not available, I have taken to using non-static methods in the way shown below. Not exactly ideal, but I can't see any approach that makes more sense, at least not for me.
public interface IZeroWrapper<TNumber> {
TNumber Zero {get;}
}
public class DoubleWrapper: IZeroWrapper<double> {
public double Zero { get { return 0; } }
}
As per Object oriented concept Interface implemented by classes and
have contract to access these implemented function(or methods) using
object.
So if you want to access Interface Contract methods you have to create object. It is always must that is not allowed in case of Static methods. Static classes ,method and variables never require objects and load in memory without creating object of that area(or class) or you can say do not require Object Creation.
Conceptually there is no reason why an interface could not define a contract that includes static methods.
For the current C# language implementation, the restriction is due to the allowance of inheritance of a base class and interfaces. If "class SomeBaseClass" implements "interface ISomeInterface" and "class SomeDerivedClass : SomeBaseClass, ISomeInterface" also implements the interface, a static method to implement an interface method would fail compile because a static method cannot have same signature as an instance method (which would be present in base class to implement the interface).
A static class is functionally identical to a singleton and serves the same purpose as a singleton with cleaner syntax. Since a singleton can implement an interface, interface implementations by statics are conceptually valid.
So it simply boils down to the limitation of C# name conflict for instance and static methods of the same name across inheritance. There is no reason why C# could not be "upgraded" to support static method contracts (interfaces).
An interface is an OOPS concept, which means every member of the interface should get used through an object or instance. Hence, an interface can not have static methods.
When a class implements an interface,it is creating instance for the interface members. While a static type doesnt have an instance,there is no point in having static signatures in an interface.
Imagine the following two classes:
class A
{
public A()
{
}
}
class B : A
{
public B()
{
}
}
Is it possible for me to define A, or alternatively an interface, in a way that forces class B to have a parameterless constructor? Or, more generalized, a constructor (or static method) that is able to create an instance of type B with a given signature?
I do not want to restrict class B to only be constructible using that signature, but I want to be sure that class B can be constructed with this signature (be it parameterless, or specifying certain parameters).
To be clear: I am not searching for a solution that would require me to use Reflection or any other method to figure that out at runtime (I don't have a problem with it, but it would make the code less readable, and generally seems like a bad idea in this case).
Is there a way to accomplish this?
I wrote a blog post that goes more in-depth about what I am trying to achieve here
There is no interface or base type that you can apply to the type to ensure it has a parameterless constructor. The only context in which you can make such a contraint is generic constraints:
public static void Foo<T>()
where T : new() {}
In such a case the only types that can be used with Foo must have a parameterless constructor.
You can define factory for instantiating objects of type A (and derived types):
interface IFactory<T> where T : A
{
T Create(int i);
T Create(string s);
// and so on...
}
and require factory implementation, when you want to create an object.
This will make sure calling code in compile time, that it tries to create an object with the given set of parameters.
Of course, there's nothing preventing from NotImplementedException from concrete IFactory<T> implementation at run-time.
This is a followup, since I did a little bit of research and at least managed to come up with an answer that is somewhat satisfying.
So after digging around a while and trying to figure out how the built-in serialization/deserialization in C# works, I found out that C# has a method called GetUninitializedObject(). This method seems like a hack, since it just avoids calling the constructor of the object in the first place, but it at least gives me a way to accomplish what I originally wanted: Being able to deserialize an object of an arbitrary type. Using this, I am able to use methods on the uninitialized created objects (and forcing their implementation via an interface).
I find this to be fitting my needs, although it does not do what I originally wanted to, it allows me to implement a pattern that works for my purposes.
Best Regards