¿Cómo evitar que una clase abstracta con clases públicas derivadas se herede en otros ensambles?

Question

Quiero escribir algo como lo siguiente:

internal class InternalData 
    { 
    } 

    public class PublicData 
    { 
    } 

    abstract internal class Base { 
     internal Base() { } 

     private static InternalData CreateInternalDataFromPublicData(PublicData publicData) 
     { 
      throw new NotImplementedException(); 
     } 

     abstract protected void DoProcess(InternalData internalData); 

     public void Process(PublicData publicData) 
     { 
      InternalData internalData = CreateInternalDataFromPublicData(publicData); 
      DoProcess(internalData); 
     } 
    } 

    public sealed class Derived : Base 
    { 
     protected override void DoProcess(InternalData internalData) 
     { 
      throw new NotImplementedException(); 
     } 
    } 

Es decir, Base contiene algo de lógica interna y no está destinada a ser heredado por clases fuera de mi montaje; y Derived es accesible desde el exterior. InternalData también contiene un poco de lógica interna y, como lo haría (y nunca debería) ser utilizado desde el exterior, también quiero que sea interno.

Por supuesto, el código anterior no se compilará, ya que Base no debería ser menos accesible que Derived. Puedo configurar el Base para que sea public, eso está bien, pero lleva a otro problema. Si Base es público, entonces podría haber alguno ExternalDerived : Base en otro ensamblaje. Pero Base.DoProcess acepta un argumento InternalData, por lo que ExternalDerived no puede implementarlo (ya que no conoce el InternalData). El constructor interno sin parámetros Base impide la creación de instancias ExternalDerived, y por lo tanto, nadie implementará ExternalDerived.DoProcess y no se necesita la exposición pública InternalData, pero el compilador no lo sabe.

¿Cómo puedo reescribir el código anterior para que haya un método abstracto DoProcess(InternalData) y para que la clase InternalData sea interna?

Answer 1

El conjunto Base es public.

public abstract class Base {... 

Cambio Base.DoProcess:

protected virtual void DoProcess<T>(T internalData) 
{ 
    if (!(internalData is InternalData)) 
    { 
     throw new ArgumentOutOfRangeException("internalData"); 
    } 
} 

Cambio Derived.DoProcess:

protected override void DoProcess<T>(T internalData) 
{ 
    base.DoProcess(internalData); 
    // Other operations 
} 

Answer 2

Huele como debería usar composition instead of inheritance. lo siento, esta es una respuesta muy vaga. Estoy pensando más sobre esto ahora ..

Answer 3

Para hacer InternalData interna, DoProcess debe ser private o internal (o InternalAndProtected, pero C# no es compatible con esta función CLR). No puede ser protected o protected internal.

internal abstract DoProcess(InternalData internalData); 

---

yo probablemente también agrego un miembro de internal abstract void DoNotInheritFromThisClassInAnOutsideAssembly(). Eso evita que cualquiera fuera del ensamblado herede de su clase, porque no pueden implementar ese miembro y obtienen un error de compilación razonable. Pero no puede hacer que la clase Base sea interna.

---

Consideraré la refacturación del código, para que no tenga una clase base común. Probablemente usando algunas interfaces y composición internal.

Answer 4

El tipo de base debe ser accesible, porque de lo contrario, se hace imposible averiguar su base . Su Base deriva directamente de System.Object, pero ¿cómo sabe un usuario de Derived? ¿Cómo sabe que Base no se deriva de otro tipo público, y los miembros de ese tipo deberían estar disponibles?

Si marca todo en Base interno, a excepción de la propia clase, ya ha impedido que otros ensambles hagan algo útil con ella. En otras palabras, si hace DoProcess interno, puede evitar que InternalData se convierta en public.

Sí, admite que esto permite errores en su propio ensamblaje, si otras clases intentan llamar al DoProcess. Desafortunadamente, no existe un modificador de acceso "accesible desde clases derivadas en el mismo ensamblado", solo "accesible desde clases derivadas", "accesible desde el mismo ensamblado" y "accesible desde clases derivadas y accesible desde el mismo ensamblado". (En realidad, .NET sí lo admite, pero C# no).

Answer 5

En realidad, es bastante sencillo. Solo requiere que una clase derivada implemente un método interno abstracto. Las clases fuera de la biblioteca no podrán implementar el método abstracto y, por lo tanto, fallarán en el momento de la compilación.

Su ejemplo, minimizado en los aspectos básicos:

abstract internal class Base { 
    internal protected abstract void DoProcess(); 

    public void Process() { 
     DoProcess(); 
    } 
} 

public sealed class Derived : Base { 
    internal protected override void DoProcess() { 
     throw new NotImplementedException(); 
    } 
}