Option to demand implementations of interfaces/abstract classes only within the assembly that created them.

[Lucasharskamp]

• Introduction

Let us assume the following context: I have an interface or abstract class that specifies a number of methods and properties, which then will need an entity that implements these things in full. For the sake of security, users of the DLL of this library are not allowed to create their own custom implementations, but rather to use one of the existing implementations made available to them by the library itself.

I don't know what new keyword would fit, so for now let's call it 'local' (but I think there are better terms for ''only implemented locally''. localseal? localimpl?)

This means that the application (or other library) using this assembly is allowed to know about the interface and abstract class and is allowed to use them and call the methods and properties as specified by the contract, but aren't allowed to override them.

• Why: prevent unwanted implementations

This prevents a junior programmer or some third party from abusing the API of the library as it was intended and cause unwanted behavior. Or maybe the code belongs to a firm who wants the behaviors of IFoo and its implementation Foo to be contained in a neat shared library, and not end up with a hundred implementations of IFoo floating around the code of their different products. I've seen this happen at previous employers where IFoo was implemented again and again, although this wasn't intended; it was intended that implementation Foo be used, although this information was lost in time.

• Why: prevent abuse

To prevent the worst case scenario, this prevents one from creating a library which doesn't do what the original interface's contract demands at all but rather does something else for nefarious means. (e.g. the interface is about calling a Web API, but the implementation also turns your computer in a bitcoin miner, and since mr. programmer is in a hurry he just grabs the first nuget package he sees of an implementation).

• Why: prevent bugs caused by interface contract violation in implementation

It could also cause bugs where a third party implements the interface, and doesn't do exactly what the original programmers of the interface intended, so when the interface is called from within the original assembly, it could cause bugs.

Example:

public interface IFoo
{
     public string BarWithValue();
}

In this example, BarWithValue() shouldn't return null since it would disrupt the behavior of the original assembly. So let's assume a third party does the following:

// somewhere in the original Library where IFoo comes from.
public static class LibraryServiceClass 
{
     public void userDecicedService(IFoo foo) 
     {
           IFoo userDecicedService = foo;
           SetBar(userDecicedService .BarWithValue()) // throws exception if null was provided.
     }
}

...

// application using the library, written by a third party:
public class Foo : IFoo
{
     public string BarWithValue() { return null; }
}
...
// application using this library
LibraryServiceClass.SetFooHandler(new Foo());

In this case, a third party misused the library, and we only want them to enact behaviors that we allow as specified by the interface contract.

• The solution: allow the library to demand local implementations only to ensure interface contract adherence

For interfaces, implementing this is simple:

public local interface IFooInterface 
{
   public string Bar();
}

Examples:

// in the original library:
public class FooImplementation : IFooInterface // this is fine!
{
     public string Bar() { return "X"; }
}
...

// in the assembly that uses this interface:
IFooInterface a = new FooImplementation(); 
return a.Bar(); // this is fine!

this would be allowed, since we're using the implementations as specified in the API of the library we're using. FooImplementation was created in the original library as well. The using assembly knows what IFooInterface is, it's not hidden and we are allowed to use its properties and methods as-is. The only thing we're not allowed to do is override them. The following would cause an error:

public class NewImplementationForFoo : IFooInterface // Error: cannot implement local interfaces outside the assembly that established them!

If the entire interface or abstract class is marked local this is all pretty simple; use them as much as you like since it's simply a contract, but you're not going to make your own implementation.

If you want to mark specific properties or methods as local, however, this can be a bit more specific: for example:

public abstract class Foo
{
      public abstract void Bar();
      public local abstract void FooBarOne();
      public local virtual void FooBarTwo() { .. }
}

If we were to override the Foo class outside the assembly where it was established, this would mean we cannot override an existing implementation of Foo: we can override Bar, but not FooBarOne

That would make the following illegal if FooImpl isn't part of the assembly as Foo:

public class FooImpl : Foo // Error: 'Foo' contains methods that are marked as only overridable by the local assembly!
{
      public override void Bar() { ... }
      public override void FooBarOne() { .. }
}

This means that, if we want to expose abstract class FooImpl to the outside world, the methods marked local from the original would need to have been implemented. That means the following (where FooImpl is from the same assembly as Foo) is legal behavior:

// in the assembly where Foo was established:
public abstract class FooImpl : Foo
{
      public local override void FooBarOne() { .. }
     // FooBarTwo doesn't need to be implemented since that is a virtual function that already contained a body
}

// in the third party application where we use FooImpl:
public sealed class FooFinal: FooImpl  // this is fine!
{
      public override void Bar() { ... } // this is fine!
      public override void FooBarTwo() { .. } // this is not fine!
}

Note: the overridden methods marked local must be marked as either local again or as sealed, for obvious reasons.

• Potential issues

1. If the library doesn't create implementations of these local interfaces or abstract classes (or their methods/properties), it renders them unusable. Upon compilation, a warning or error must be given that no implementations exist that one can use when using the library.
2. Compiler Warning/Info: Specifying local methods/properties is kind of redundant if the entire interface/abstract class is specified local as well.
3. Compiler Error/Warning/Info: trying to define a private or internal entity as local, or an entity that cannot be overridden anyways as local. For example: public sealed local override FooBarImplementation() { .. } is kind of redundant.
4. Another question is whether to allow extension methods for local interfaces or abstract classes, although I don't think that should be a problem and should be allowed since they're not part of the original object anyway.

[HaloFour]

If you declare an internal constructor on an abstract class that will force it so that only classes within the same assembly can derive from that abstract class.

[Lucasharskamp]

Make the interface internal. Have strong typed entry points for all the supported types. Delegate internally to working on the interface.

Again, dependency injection. Let's assume the following: we're using a dependency injection of interface IFoo with implementation class Foo. The service itself is handled by extending the service collection and calling said extension method in the program we're we are using the library:

public static IServiceCollection SetupFoo(this IServiceCollection services) { return services.AddSingleton<IFoo, Foo>(); }

Using your example, I wouldn't be able to call IFoo since IFoo is marked as internal. And since the injection is always the left-hand side object, I can't use it in the application where I'm implementing the dependency injection. And no, we simply cannot let IFoo out the door and just use Foo: there are other DI's which use IFoo's methods, but have a different implementation (e.g. FooTwo)

[Lucasharskamp]

I didn't know what DI changes here.

Please read before answering: as mentioned before, you cannot use non-public constructors for Di's. And there are also cases where you'd want a public parameterless constructor.

[HaloFour]

Nothing limits the constructors of the implementing classes from being public. Dependency injection should be fine with this strategy, given the DI container needs to know which implementation goes with the contract anyway.

The compiler and language don't really care about the limitations of particular dependency injection containers. It'd be on them to correctly handle how the language and runtime implement things.

[333fred]

DI isn't going to be making an instance of the abstract class anyway, so I don't understand the resistance to that solution? You can derive from the abstract class and mark that sealed; that derived type can have a public constructor, no one can inherit it, and no one external can inherit the abstract class because of the internal constructor.

[CyrusNajmabadi]

Please read before answering:

I did read it.

as mentioned before, you cannot use non-public constructors for Di's. And there are also cases where you'd want a public parameterless constructor.

I don't see what that has to do with abstract class. That might be a requirement of your DI system for the derived types. But those are not affected by what I am saying.

Furthermore, this appears to an issue with the DI system you're using. We can't provide solutions at the language level because, for all we know, that DI system simply will not support anything we create.

[colejohnson66]

The best you can get (out of the box) would be a custom analyzer that raises errors when library consumers implement your interface.

However, there is another, more interesting way, that can be used: IL rewriting. Avalonia, for example, have an attribute [NotClientImplementable] they tag to interfaces. Then, during build, they inject in a method with an "unspeakable" name, (This interface or abstract class is -not- implementable by user code !).

If you try to implement any of those interfaces, you get a compiler error about the method you "forgot" to implement:

public class MyCustomPen : IPen
{
    public IBrush? Brush { get; }
    public IDashStyle? DashStyle { get; }
    public PenLineCap LineCap { get; }
    public PenLineJoin LineJoin { get; }
    public double MiterLimit { get; }
    public double Thickness { get; }
}

Produces:

Interface member 'void Avalonia.Media.IPen.(This interface or abstract class is -not- implementable by user code !)()' is not implemented