¿Cuáles son los beneficios de usar una clase parcial en lugar de una clase abstracta?

Question

He estado leyendo Programando Microsoft® Visual C# ® 2008: El lenguaje para obtener una mejor comprensión de C# y qué se puede hacer con él. Encontré clases parciales que ya había encontrado en la clase de página de ASP.Net.

Para mí, parece que puede hacer lo que hacen las clases parciales con una clase abstracta y una anulada. Obviamente, un equipo tendrá el control de la interfaz a través de los métodos abstractos, pero de todos modos confiaría uno en el otro. Y si el objetivo es la colaboración, no es eso lo que el control de la fuente y otras herramientas resuelven.

Solo estoy perdiendo el sentido de una clase parcial. También podría alguien proporcionar un uso real del mundo.

Answer 1

Las clases parciales no tienen nada que ver con la herencia de objetos. Las clases parciales son solo una manera de dividir el código fuente que define una clase en archivos separados (esto se hace, por ejemplo, cuando crea un nuevo formulario en su aplicación Windows Forms: un archivo es "su" código, otro archivo .designer.cs contiene el código que VS2008 administra para usted).

Answer 2

Un buen ejemplo de uso es cuando se genera un lado de la clase parcial (como un ORM)

Answer 3

Propósito de las clases parciales es permitir la definición de una clase para extenderse a lo largo de varios archivos. Esto puede permitir un mejor mantenimiento y separación de su código.

Answer 4

Utilizamos clases parciales para dividir nuestras clases más grandes. De esta forma, es más fácil verificar una parte del código con Sourcesafe. Esto limita los casos en que cuatro desarrolladores necesitan acceder al mismo archivo.

Answer 5

Lo bueno de una clase parcial es que puede tomar una clase existente y agregarla. Ahora esto se parece mucho a la herencia, pero hay muchas cosas que la herencia no puede hacer que las clases parciales lo hagan.

Aquí hay una idea sobre las clases de SQL de Linq generadas para usted. Se autogeneran, lo que significa que no debes modificarlos. Sin una clase parcial, no puede adjuntar una interfaz. Puedes crear una nueva clase y derivarla de la clase Linq a sql, pero eso realmente no te da nada porque no puedes subir la clase linq a sql a tu clase con la interfaz.

Answer 6

La clase parcial ahora se usa mucho en ASP.Net para permitir que dos archivos fuente el ejemplo basado en el marcado example.aspx y el ejemplo basado en código.aspx.cs para que los métodos y la variable definidos en cada uno sean visibles para cada uno. en el example.aspx

<custom:exampleControl id="exampleCntr" property="<%#getProperty()%>" /> 

en los example.aspx.cs

private object GetProperty(){ // called from aspx 
    return DateTime.Now; 
} 

private void DoStuff(){ 
    ExampleControl c = exampleCntr; //exampleCntr is defined in aspx. 
} 

La naturaleza bi-direccional de esto no puede ser recreada con clases abstractas.

Answer 7

Las clases parciales se deben restringir al uso con código generado automáticamente, donde el otro código no se puede modificar. Usarlo como un sustituto de la herencia o agregar funcionalidad no son las mejores prácticas.

Si tiene una clase grande, ya está mal. El código se debe refactorizar en múltiples clases "reales" en lugar de múltiples archivos. Las clases grandes en general significan que la clase está haciendo demasiadas cosas y viola el SRP (principio de responsabilidad única).

Answer 8

Parece que su pregunta es ¿cuál es la diferencia entre

partial class Foo 
{ 
    PART ONE 
} 
partial class Foo 
{ 
    PART TWO 
} 

y

astract class FooBase 
{ 
    PART ONE 
} 
partial class Foo : FooBase 
{ 
    PART TWO 
} 

Si bien pueden parecer algo similar y en algunos casos la construcción de este último podría ser utilizado en lugar de el primero, hay al menos dos problemas con el último estilo:

-1- El tipo FooBase probablemente tenga que conocer la identidad de el tipo concreto que se suponía que derivaría de él, y siempre usa variables de ese tipo, en lugar de usar el tipo FooBase. Eso representa un acoplamiento incómodamente cerrado entre los dos tipos.

-2- Si el tipo Foo es público, el tipo FooBase también debería ser público. Incluso si todos los constructores de FooBase son internal, es posible que el código externo defina las clases que derivan de FooBase pero no Foo; construir instancias de tales clases sería difícil, pero no imposible.

Si fuera posible para un tipo derivado ampliar la visibilidad de un tipo base, estos problemas no serían demasiado problemáticos; uno consideraría FooBase como un identificador "desechable" que aparecería exactamente dos veces: una en su declaración y otra en la línea de declaración para Foo, y suponga que cada FooBase sería Foo disfrazado. El hecho de que FooBase no pudo usar Foo miembros de instancias en this sin un tipocast podría ser fastidioso, pero también podría fomentar una buena partición del código. Sin embargo, dado que no es posible expandir la visibilidad de un tipo base, el diseño de clase abstracta parece asqueroso.