1

I often work with an Automation library that has a non-static class which references an application. In a single project, there can be dozens of classes, each with their own reference to this application. In the past I've simply made a static class, with a reference to the application, that all classes can point to:

public static class SomeAppHelper
{
    private static IApplication _app = null;
    public  static IApplication app
    {
        get
        {
            if (_app == null)
            {
                _app = new SomeApp.coApplication();
            }
            return _app;
        }
        set { _app = value; }
    }
}

I also stuff the class with useful functions that help stretch the limitations of the Automation to my needs. This has been all well and good until now, but I find myself wanting to take it a step further. I'd like to make SomeAppHelper extend SomeApp.coApplication such that users of my DLL can access functions from both my class, and the original with a simple SomeAppHelper.functionName(). Additionally, I'd very much like to keep the class static so that each class that uses it doesn't have to instantiate it.

I've messed around with basic extension syntax (public static class SomeAppHelper : SomeApp.coApplication) but because coApplication is never instantiated, it has no members.

I also toyed with the idea of trying to set this as a property which returned a SomeApp.coApplication() in a similar fashion to my original approach:

public static class SomeAppHelper
{
    private static IApplication _app = null;
    public  static IApplication this
    {
        get
        {
            if (_app == null)
            {
                _app = new SomeApp.coApplication();
            }
            return _app;
        }
        set { _app = value; }
    }
}

I'm sure anyone who's ever tried to C# at all could tell you exactly how well this went over with the compiler.

Really, I'm not so concerned with the approach I use, so much as the outcome (having a single, static class through which a developer can access functions from SomeApp.coApplication() and SomeAppHelper directly). Am I totally in pipe dream land here? It wouldn't be the end of the world if this is impossible, but it would be great to have this ability.

Erik Philips
  • 53,428
  • 11
  • 128
  • 150
Sandy Gifford
  • 7,219
  • 3
  • 35
  • 65
  • 2
    COM does not support implementation inheritance, the C# compiler will reject attempts to inherit from a coclass. Encapsulation is required. – Hans Passant Mar 14 '14 at 19:41
  • @HansPassant Interesting, I'll def go read up on that. If it weren't a COM, but just some instantiable class would this be possible? – Sandy Gifford Mar 14 '14 at 19:43

1 Answers1

1

You cannot inherit in the way you want.
How can a static class derive from an object?

But you can wrap the non static function calls into static functions on your SomeAppHelper

So for each function you want to make available on your static class you would have to do this

public static ReturnObject FunctionName(Parameters p)
{
    return _app.FunctionName(p);
}

Just make sure that _app is initialized before calling these static methods.

Community
  • 1
  • 1
Caleb
  • 1,088
  • 7
  • 7
  • I was worried it would come down to something like this. The Automation library I'm working with is rather large (and very subject to change); mirroring isn't great, but if it's the best I can do... Are there any other ways, perhaps using some other weird combinations of classes to get similar results? (I don't mind what happens in the black box, so much as I care what comes out of it). – Sandy Gifford Mar 14 '14 at 19:52
  • It all depends on how you are using `SomeAppHelper`. If the clients of your class are already dependant on the `SomeApp.coApplication()` implementation, then you gain nothing by wrapping all the functions in the static class. Just pass `_app` through and making them call the functions directly. The reason why you would be wrapping the `_app` is to abstract away from the 3rd party code. This allows your clients to not be dependent on the 3rd party code at all. You shouldn't be trying to give them access to every function of `_app`, only the ones that you want them to use. – Caleb Mar 14 '14 at 20:01
  • This is an internal DLL. It's also incredibly dated and frustrating (using it to set document content, for example, requires a whole 5 lines of code). I'm trying to make a single replacement library that gives users all of the power, without fragmenting the functions into two arbitrary categories. I think what I'll do is make the `app` available, and cherry pick the most important functions (as you suggested). Thanks for the patience in answering! – Sandy Gifford Mar 14 '14 at 20:07