Why Doesn t C Allow Static Methods to Implement an Interface

Question

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

User · Answer

Because interfaces are in inheritance structure  and static methods don t inherit well

User · Answer

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

User · Answer

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

User · Answer

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 lt T gt          need to call T IsQueryable  but can t        need to call T RowCount     need to call T DoSomeStaticMath int param         var r   GetRepository lt Customer gt     Unfortunately  I can come up only with  quot ugly quot  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   quot connected to DB quot  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

User · Answer

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

User · Answer

Because interfaces are in inheritance structure  and static methods don t inherit well

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Because interfaces are in inheritance structure  and static methods don t inherit well

User · Answer

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

User · Answer

Because interfaces are in inheritance structure  and static methods don t inherit well

User · Answer

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 lt T gt          need to call T IsQueryable  but can t        need to call T RowCount     need to call T DoSomeStaticMath int param         var r   GetRepository lt Customer gt     Unfortunately  I can come up only with  quot ugly quot  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   quot connected to DB quot  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt T gt    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 lt T gt  Default    For each class T of interest  define a class or struct which implements IGetWhateverClassInfo lt T gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt T gt  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 lt T gt  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

User · Answer

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 lt T gt    List lt T gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt T gt    List lt T gt  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

User · Answer

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 lt TNumber gt      TNumber Zero  get      public class DoubleWrapper  IZeroWrapper lt double gt      public double Zero   get   return 0

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt T  Tk gt        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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt T gt  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 lt T gt  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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt TNumber gt      TNumber Zero  get      public class DoubleWrapper  IZeroWrapper lt double gt      public double Zero   get   return 0

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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 lt T  Tk gt        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

User · Answer

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 lt T gt    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 lt T gt  Default    For each class T of interest  define a class or struct which implements IGetWhateverClassInfo lt T gt  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

[c#] Why Doesn't C# Allow Static Methods to Implement an Interface?

Examples related to c#

Examples related to oop

Examples related to language-features