I have 7 classes that (simplified) look like:

public static class ClassN {
    private static Logger MyLogger = Logger.New("ClassN");
    private static MyClass GetInstance() => new MyClass(some constant arguments);

    public static Something Get()
    {
        return MyStaticClass.Get(GetInstance(), MyLogger);
    }
}

I want to add 5 functions to each class that (again, simplified) would do something like

public static Prop1 GetProp1() {
    return Get().Prop1;
}

public static Prop1 GetProp2() {
    return Get().Prop2;
}

etc.

to simplfy some hundreds of calls of these Get functions.

Repeating the same code everywhere doesn't seem a reasonable option. I'd like to do something like

public abstract static class ClassBase {
    private static abstract Logger MyLogger;
    private static abstract MyClass GetInstance();

    public static Something Get()
    {
        return MyStaticClass.Get(GetInstance(), MyLogger);
    }

    public static Prop1 GetProp1() {
        return Get().Prop1;
    }

    public static Prop2 GetProp1() {
        return Get().Prop2;
    }

    etc.
}

and then my classes would be as simple as

public static class ClassN : ClassBase {
    
    private static MyClass GetInstance() => new MyClass(some constant arguments);
    private static Logger MyLogger = Logger.New("ClassN");
}

so that I could unambiguously call Class1.Get();, Class2.Get();, etc.

I know static classes cannot be inherited, they cannot be abstract, I can't define static virtual properties, etc. I've been reading different articles in SO and none of the solution seems as nice/simple as this one.

How can achieve a solution that looks as simple as this one? I discarded making the methods not static because these methods are called in some hundreds of places in our code and having to instantiate an object everywhere would be a pain and ugly. Also, using a Factory pattern poses similar inconvenients, etc.

I have 7 classes that (simplified) look like:

public static class ClassN {
    private static Logger MyLogger = Logger.New("ClassN");
    private static MyClass GetInstance() => new MyClass(some constant arguments);

    public static Something Get()
    {
        return MyStaticClass.Get(GetInstance(), MyLogger);
    }
}

I want to add 5 functions to each class that (again, simplified) would do something like

public static Prop1 GetProp1() {
    return Get().Prop1;
}

public static Prop1 GetProp2() {
    return Get().Prop2;
}

etc.

to simplfy some hundreds of calls of these Get functions.

Repeating the same code everywhere doesn't seem a reasonable option. I'd like to do something like

public abstract static class ClassBase {
    private static abstract Logger MyLogger;
    private static abstract MyClass GetInstance();

    public static Something Get()
    {
        return MyStaticClass.Get(GetInstance(), MyLogger);
    }

    public static Prop1 GetProp1() {
        return Get().Prop1;
    }

    public static Prop2 GetProp1() {
        return Get().Prop2;
    }

    etc.
}

and then my classes would be as simple as

public static class ClassN : ClassBase {
    
    private static MyClass GetInstance() => new MyClass(some constant arguments);
    private static Logger MyLogger = Logger.New("ClassN");
}

so that I could unambiguously call Class1.Get();, Class2.Get();, etc.

I know static classes cannot be inherited, they cannot be abstract, I can't define static virtual properties, etc. I've been reading different articles in SO and none of the solution seems as nice/simple as this one.

How can achieve a solution that looks as simple as this one? I discarded making the methods not static because these methods are called in some hundreds of places in our code and having to instantiate an object everywhere would be a pain and ugly. Also, using a Factory pattern poses similar inconvenients, etc.

• c#

• Does each of the 7 static classes wrap the same MyClass/MyStaticClass pair? – Mathias R. Jessen Commented Mar 14 at 17:53
• MyClass are actually different implementations of an interface. MyStaticClass is always the same – xavier Commented Mar 14 at 18:00
• 1 And the reason for using static classes in the first place? It appears these problems could be solved by using an abstract + sealed implementations with a private dummy constructor that retain the static methods. – Mathias R. Jessen Commented Mar 14 at 18:06
• static classes are not necessary, but static methods are necessary to call it easily Class1.Get() without having to instantiate. I don't see how the abstract + sealed soluton would work... – xavier Commented Mar 14 at 18:16
• Looks like 7 factories that return the same object type but a different logger; and trying to link object properties (Prop1 and Prop2) to the (static) factory somehow; when one should simply return the manufactured object; access the properties via the object; and the "logger" as a "property" of the object (via an interface). A "incomplete" design never gets better unless it's fixed. – Gerry Schmitz Commented Mar 14 at 20:58

1 Answer 1

Make your classes partial, then use source code generation to do the boiler plate work and fill in the rest of the code. There's a good article on getting started here.

Source code generation has the same kind of benefits as reflection, but where reflection would force you to stay in the reflected world for every call to a method or property, source code generation actually creates the classes (or in this case, the partial classes) that can then be used and called directly, just like any other code.