Cómo crear una clase que sea abstracta, pero no internamente

Question

¿Es esto posible en C# de alguna manera? Este es el caso exacto para el que lo necesito: Él (el usuario) no debe poder crear instancias de esta clase. Sin embargo, quiero poder crear instancias de esta clase dentro de mi proyecto. (por lo tanto, internamente) Otras clases deberían poder heredar de él. Quiero obligar al usuario a usar solo la clase Sound más grande. El gran "PERO": el usuario debe poder usar instancias de esta clase si se lo doy, es por eso que no puedo hacerlo interno y terminarlo. Tampoco puedo hacerlo abstracto porque quiero hacer copias yo mismo. Pensé en darle al usuario solo interfaces como IChannel, pero eso no resuelve mi problema de que no debería poder hacer una instancia de Channel. Todavía podrá ver la clase si la busca, y si es lo suficientemente aventurero, incluso intenta crear una instancia. Pero como mencioné antes: no puedo hacerlo abstracto porque necesito hacer copias internamente.

¡Apreciar tu ayuda!

Answer 1

Debería poder declarar el constructor como interno y la clase misma como pública. Eso debería (creo) darte lo que quieres.

Answer 2

Constructor interno.

Answer 3

¿No debería un constructor internal resolver el problema? De esta forma, solo su ensamblado puede crear instancias, pero el usuario puede seguir usando instancias sin restricciones.

Answer 4

¿Solo hace que el constructor de la clase sea interno?

Answer 5

Siempre se puede controlar la creación de instancias utilizando diferentes modificadores en el constructor:

public class MyClass 
{ 
    internal MyClass() 
    { 
    } 
} 

Ahora nadie puede crear una instancia de la clase, pero si se les da una instancia que puede trabajar con él como si fuera normal.

Answer 6

Como muchas otras personas mencionaron, puede tener un constructor interno en una clase pública.

Sin embargo, proporcionaría al cliente una interfaz pública y haría que toda la clase fuera interna (o abstracta si desea que el cliente pueda subclasificarla). De esta forma, usarán la interfaz, lo que les facilitará la prueba unitaria de su código. Le dará flexibilidad para cambiar la implementación en el futuro.

Answer 7

El uso de un constructor de ámbito interno le permitirá crear subclases dentro del mismo conjunto o cualquier otro ensamblaje al que haya hecho visibles las partes internas. Sin embargo, evitará la creación de subclases en otros ensambles, ya que cada clase derivada de otra se requiere para llamar a un constructor en la clase base. Si su constructor no está disponible en función de su alcance, esto evitará que otros se deriven de su clase.

En general, no me gusta este tipo de pensamiento, sin embargo. Como desarrollador, es realmente molesto descubrir que el desarrollador de una API que estoy utilizando piensa que sabe todo sobre cómo quiero usarlo. Sí, oculte los detalles internos de la implementación si es necesario, pero permítame extender la API para hacer lo que necesito (y usted no ha pensado) y no me haga saltar por los aros para hacerlo.

Ah, y sí, cree una interfaz y utilícela como devolución. Harás que mi vida sea más fácil a largo plazo, además de que será mucho más fácil burlar tu código en mis pruebas unitarias.

Answer 8

Creo que lo que quiere es una clase con un constructor publicprotected y un método internal fábrica:

public class MyClassWhichIsAbstractExceptForMe 
{ 
    // Allow derived classes but prevent public construction. 
    protected MyClassWhichIsAbstractExceptForMe() 
    { 
    } 

    // Allow internal construction 
    internal static MyClassWhichIsAbstractExceptForMe Create() 
    { 
     return new MyClassWhichIsAbstractExceptForMe(); 
    } 
} 

también recomiendo suavemente una revisión del diseño. Esto parece bastante extraño, como otros han señalado.