Can I disallow other assemblies from inheriting from a class?

Question

I've got something like this:

// This gets implemented by plugin authors to get callbacks about various things.
public interface ExternalPlugin
{
    // This gets called by the main application to tell the plugin some data
    // is available or similar.
    void DoStuff(SomeDataBlob blob);
}

// Data blob for v1 of API
public class SomeDataBlob
{
    internal SomeDataBlob(string prop) { Prop = prop; }
    // Some piece of data that V1 plugins need
    public string Prop { get; private set; }
}

// FUTURE!
// Data blob API v2 of API
public class SomeDataBlobV2 : SomeDataBlob
{
    // Can be passed to clients expecting SomeDataBlob no problem.
    internal SomeDataBlobV2(string prop, string prop2) :base(prop) { Prop2 = prop2; }
    // Some piece of data that V2 plugins need. V2 plugins can cast to this from
    // SomeDataBlob, but still can load successfully into older versions that support
    // only V1 of the API
    public string Prop2 { get; private set; }
}

I have to make SomeDataBlob public so that it can be used as a member of the public interface method ExternalPlugin.DoStuff. However, I would not like to allow clients to inherit from that class and thus be susceptible to the brittle base class problem. (All derivatives of that class should be kept in the same assembly)

Marking the class sealed goes too far because I believe removing sealed is a breaking API change; and even if that isn't, once I ship SomeDataBlobV2 clients could still do the wrong thing and inherit from SomeDataBlob directly.

Is there a way to enforce this kind of pattern?

Answer 1

Make the class internal, and expose an interface instead. Then use the factory pattern to create the correct implementation.

public interface ISomeDataBlob
{
}

internal class SomeDataBlob : ISomeDataBlob
{
}

public class BlobApiFactory
{
    ISomeDataBlob Create();
}

You hide the implementation, but still give the user access to everything. You even make unit tests easier for your users ;)

Edit (answer to a comment from the OP)

What I effectively want is some method taking some parameters. I want to be able to add parameters that the main application can provide in a future version if the API without breaking clients. But I don't want clients to be able to create instances of the "parameters" class/interface or otherwise interact with it beyond receiving an instance of it as a parameter

Instead of hiding the APIs you can make sure that all object passed to your library originates from your assembly:

public class YourCoolService
{
    public void DoSomething(ISomeDataBlob blob)
    {
        if (blob.GetType().Assembly != Assembly.GetExecutingAssembly())
            throw new InvalidOperationException("We only support our own types");
    }
}

Edit2

Just noticed that @RQDQ already provided that solution (didn't notice when answering your comment). If that's the solution you want, accept his answer instead.

Answer 2

  /// <summary>
  /// This is a dummy constructor - it is just here to prevent classes in other assemblies
  /// from being derived from this class. 
  /// See http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2971840&SiteID=1
  /// </summary>
  internal MhlAdminLayer() { }

The idea is to have a constructor with no parameters internal. Then the class can't be derived from.

Edit: Sorry, the link in the comment doesn't work any more.

Edit 2: http://msdn.microsoft.com/en-us/library/vstudio/ms173115.aspx

"You can prevent a class from being instantiated by making the constructor private ... "

Answer 3

If you are hell bent on not using sealed AND still using classes, you can enforce this at runtime. In otherwords, at your API boundary, inspect the classes involved and make sure they come from your assembly.

A simple example:

public void Bar(Foo foo)
{
    if (foo.GetType().Assembly != this.GetType().Assembly)
        throw new InvalidOperationException("It's not one of mine!");
}

public class Foo
{
}

Answer 4

As far as I know, interfaces are the way to do this. It would be an API breaking change, but it would mean you could do what you want.

public interface ExternalPlugin
{
    void DoStuff(ISomeDataBlob blob);
}
// Interfaces:
public interface IDataBlob
{
    string Prop { get; }
}
public interface IDataBlobV2 : IDataBlob
{
    string Prop2 { get; }
}
// Data blob for v1 of API
internal class SomeDataBlob : IDataBlob
{
    internal SomeDataBlob(string prop) { Prop = prop; }
    public string Prop { get; private set; }
}
// FUTURE!
// Data blob API v2 of API
public class SomeDataBlobV2 : SomeDataBlob, IDataBlobV2
{
    // Can be passed to clients expecting SomeDataBlob no problem.
    internal SomeDataBlobV2(string prop, string prop2) : base(prop) { Prop2 = prop2; }
    public string Prop2 { get; private set; }
}

And then to make the objects use the factory pattern, e.g.

public static class DataBlobFactory
{
    public IDataBlob GetDataBlob(string prop)
    {
        return new SomeDataBlob(prop);
    }
    // so on.
}

Answer 5

What I would do is make some sort of factory class that exposes an interface that would pass an instance of whatever version for the specific API your client is using, and hide the implementation with an internal class

You can also use constraints to make it little easier to use, then the client can just put the Type of object they are looking for

public interface IBlobV1 { /*public stuff for V1 here*/ } 
internal class BlobV1: IBlobV1 {/*v1 implementation*/ }

public interface IBlobV2 : IBlobV1 {/*public interface for V2 here*/ }
internal class BlobV2:BlobV1,IBlobV2 {/*v2 implementation*/} 



public sealed BlobFactory 
{
    public IBlobV1 CreateVersion1Blob(){/* implementation */} 
    public IBlobV2 CreateVersion2Blob(){/* implementation */}
    public T CreateBlob<T>() 
           where T: IBlobV1
    { /* implementation */}
}

Answer 6

SomeDataBlob can not be inherited because its only constructor is internal. If you try to implement a derived class in a client application:

class SomeDataBlobClient : SomeDataBlob
{
    SomeDataBlobClient():base("TEST")
    {

    }
}

You will get the following error:

The type 'ClassLibrary1.SomeDataBlob' has no constructors defined

It seems that you solved your own problem.