C# static member “inheritance” - why does this exist at all?

前端 未结 7 1177
忘掉有多难
忘掉有多难 2020-11-27 19:32

In C#, a superclass\'s static members are \"inherited\" into the subclasses scope. For instance:

class A { public static int M() { return 1; } }
class B : A         


        
相关标签:
7条回答
  • 2020-11-27 19:46

    I rather have access to all my based static members in derived classes. Otherwise i would need to know exactly where the static member was defined and call it explicitly.

    When using Intellisense you can automatically know every static member available to that kind of class.

    Of course, they are not inherited, it's just a shortcut

    0 讨论(0)
  • 2020-11-27 19:46

    I always see it a means of preventing any form of polymorphism by the inheriting class on those items that you wish to retain the same function for all child classes.

    ignore the above for some reason I was thinking of sealed instead of static

    I suppose that you'd use static member variables and functions in order to ensure that any data or functionallity is not dependent on the a class instance as it would be instantiated only the once.

    An example of use would be say a counter value that would keep a live count of all instances of a superclass's subclasses (each subclass increments the static count value on construction). This count value would be available and equal for all instances of the subclass.

    0 讨论(0)
  • 2020-11-27 19:56

    I think it's for accessing protected static members of the base class.

    class Base
    {
        protected static void Helper(string s)
        {
           Console.WriteLine(s);
        }
    }
    
    class Subclass : Base
    {
       public void Run()
        {
           Helper("From the subclass");
        }
    }
    
    0 讨论(0)
  • 2020-11-27 19:58

    That's how it works, would probably just be a stupid answer in most cases. But in this case, it is how it works; since you derive from A you say that you are A + the extra features you add.

    Therefore you need to be able to access the same variables that you would through an instance of A.

    However, inheriting a static class makes no sense while access to the static members / fields / methods does.

    An example of this is the following:

    internal class BaseUser
    {
        public static string DefaultUserPool { get; set; }
    }
    internal class User : BaseUser
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public User Parent { get; set; }
    }
    

    Where the test looks like this:

    User.DefaultUserPool = "Test";
    BaseUser.DefaultUserPool = "Second Test";
    
    Console.WriteLine(User.DefaultUserPool);
    Console.WriteLine(BaseUser.DefaultUserPool);
    

    Both of the WriteLines outputs "Second Test", this is because both BaseUser and User should use DefaultUserPool, by design. And overriding static implemented methods wouldn't make mucn sense since it's just an accessor in the child-class.

    There can be only one. Overriding it would mean that there's a new implementation for that sub-class, which would kill the term "static".

    0 讨论(0)
  • 2020-11-27 20:01

    Actually, as I understand it, this is just a shortcut provided by the compiler. Syntax sugar. B.M() will just compile to A.M() since B does not have a static M() and A does. It's for easier writing, nothing else. There is no "static inheritance".

    Added: And the requirement for new when "redefining" is just so that you don't accidentally shoot yourself in the foot.

    0 讨论(0)
  • 2020-11-27 20:06

    So, the "inheritance" of static members merely looks like namespace pollution

    That's right, except that one guy's pollution is another guy's added spicy flavouring.

    I think Martin Fowler, in his work on DSLs, has suggested using inheritance in this way to allow convenient access to static methods, allowing those methods to be used without class name qualification. So the calling code has to be in a class that inherits the class in which the methods are defined. (I think it's a rotten idea.)

    In my opinion, static members should not be mixed into a class with a non-static purpose, and the issue you raise here is part of the reason why it's important not to mix them.

    Hiding private static mutable data inside the implementation of an otherwise "instancey" class is particularly horrible. But then there are static methods, which are even worse mixers. Here's a typical use of static methods mixed into a class:

    public class Thing
    {
        // typical per-instance stuff
        int _member1;
        protected virtual void Foo() { ... }
        public void Bar() { ... }
    
        // factory method
        public static Thing Make()
        {
            return new Thing();
        }
    }
    

    It's the static factory method pattern. It's pointless most of the time, but even worse is that now we have this:

    public class AnotherThing : Thing { }
    

    This now has a static Make method which returns a Thing, not a AnotherThing.

    This kind of mismatch strongly implies that anything with static methods should be sealed. Static members fail to integrate well with inheritance. It makes no sense to have them heritable. So I keep static things in separate static classes, and I gripe about redundantly having to declare every member static when I've already said that the class is static.

    But it's just one of those too-late-now things. All real, working languages (and libraries, and products) have a few of them. C# has remarkably few.

    0 讨论(0)
提交回复
热议问题