Patrón Partial Class: Ejemplos

Descripción General

El Patrón Partial Class divide la definición de una única clase en múltiples archivos fuente. En tiempo de compilación, los fragmentos se fusionan en un único tipo. Esta separación permite que el código auto-generado (de designers, ORMs o generadores de código) viva en un archivo mientras las customizaciones escritas a mano viven en otro, sin riesgo de que uno sobrescriba al otro.

Aunque más asociado con C# (partial class), el concepto existe en otras formas: Ruby permite reabrir clases, Python permite monkey-patching, y los métodos default de interfaces de Java más records logran objetivos similares. El beneficio core es separación organizacional sin overhead en runtime.

Cuándo Usar

• For alternatives, see Marker Interface Pattern.

Usa el Patrón Partial Class cuando:

• Los generadores de código producen boilerplate grande que no debería editarse manualmente
• La lógica de negocio escrita a mano debería mantenerse separada del código scaffolded
• Múltiples desarrolladores trabajan en diferentes aspectos de la misma clase simultáneamente
• Quieres organizar una clase grande por concern (persistencia, validación, serialización)

Cuándo Evitar

• La clase es lo suficientemente pequeña para caber cómodamente en un único archivo
• Los splits crean dependencias circulares o navegación confusa
• El lenguaje no soporta tipos parciales nativamente (workarounds agregan complejidad)
• El patrón se usa para esconder que una clase creció demasiado (refactorizar en su lugar)

Solución

C# (Nativo)

// AutoGenerated.cs — generado por herramienta, no editar
public partial class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}

// Customer.Custom.cs — lógica de negocio escrita a mano
public partial class Customer
{
    public bool IsValidEmail()
    {
        return Email?.Contains("@") ?? false;
    }

    public string GetDisplayName()
    {
        return $"{Name} <{Email}>";
    }
}

Python

Python no tiene partial classes, pero las clases pueden reabrirse y monkey-patchearse:

from dataclasses import dataclass

# Archivo: customer_base.py (auto-generado)
@dataclass
class Customer:
    id: int
    name: str
    email: str


# Archivo: customer_custom.py (escrito a mano)
def is_valid_email(self) -> bool:
    return "@" in self.email if self.email else False

def get_display_name(self) -> str:
    return f"{self.name} <{self.email}>"

# Reabrir la clase adjuntando métodos
Customer.is_valid_email = is_valid_email
Customer.get_display_name = get_display_name


# Uso
customer = Customer(id=1, name="Alice", email="alice@example.com")
print(customer.is_valid_email())       # True
print(customer.get_display_name())    # Alice <alice@example.com>

Java

Java no tiene partial classes, pero nested classes, métodos default de interfaces y records con builders logran separación similar:

// Base auto-generado
public class CustomerBase {
    private final int id;
    private final String name;
    private final String email;

    public CustomerBase(int id, String name, String email) {
        this.id = id; this.name = name; this.email = email;
    }

    public int getId() { return id; }
    public String getName() { return name; }
    public String getEmail() { return email; }
}

// Extensión escrita a mano vía herencia
public class Customer extends CustomerBase {
    public Customer(int id, String name, String email) {
        super(id, name, email);
    }

    public boolean isValidEmail() {
        return getEmail() != null && getEmail().contains("@");
    }

    public String getDisplayName() {
        return getName() + " <" + getEmail() + ">";
    }
}

// Uso
Customer customer = new Customer(1, "Alice", "alice@example.com");
System.out.println(customer.isValidEmail());
System.out.println(customer.getDisplayName());

JavaScript

JavaScript permite extender prototypes en cualquier momento, logrando comportamiento de partial class:

// Archivo: customerBase.js (auto-generado)
class Customer {
  constructor(id, name, email) {
    this.id = id;
    this.name = name;
    this.email = email;
  }
}

// Archivo: customerCustom.js (escrito a mano)
Customer.prototype.isValidEmail = function () {
  return this.email?.includes('@') ?? false;
};

Customer.prototype.getDisplayName = function () {
  return `${this.name} <${this.email}>`;
};

// Uso
const customer = new Customer(1, 'Alice', 'alice@example.com');
console.log(customer.isValidEmail());    // true
console.log(customer.getDisplayName());  // Alice <alice@example.com>

Explicación

El Patrón Partial Class resuelve un problema de tooling y mantenimiento:

• Antes: Los generadores de código sobrescriben cambios escritos a mano cada vez que corren
• Después: El código generado vive en un archivo, el código custom en otro; ambos compilan a un único tipo

Esto no es sobre comportamiento en runtime (no hay diferencia runtime entre una partial y una monolítica), sino sobre organización de código fuente y seguridad de generadores.

Variantes

Variante	Lenguaje	Mecanismo
Partial class	C#, VB.NET	Keyword partial nativo
Reopen class	Ruby, Python	Monkey-patch / reabrir en runtime
Mixin modules	Ruby, Python	Incluir módulos en clase
Default interface methods	Java	Métodos de interface con cuerpo
Partial method	C#	Stub generado, implementación opcional

Lo que funciona

• Nunca edites archivos generados. Márcalos con comentarios // <auto-generated>.
• Usa naming consistente. Customer.generated.cs y Customer.custom.cs hacen el intento claro.
• Mantén partials coherentes. Separa por concern (serialización, validación), no arbitrariamente.
• Documenta qué archivo contiene qué. Un comentario a nivel de clase ayuda la navegación.
• Regenera en CI. Asegura que los archivos generados siempre estén frescos y no modificados manualmente.

Errores Comunes

• Splitting arbitrario. Cinco archivos partial para una clase de 100 líneas es excesivo.
• Crear dependencias circulares. Los partials no deberían depender unos de otros de formas confusas.
• Mezclar código generado y escrito a mano en el mismo archivo. Derrota el propósito.
• Usar partials para evitar refactorizar. Si una clase necesita diez partials, puede necesitar extracción en clases más pequeñas.
• Asumir thread safety del splitting. Las partial classes tienen la misma semántica de threading que las clases regulares.

Ejemplos del Mundo Real

WinForms / WPF Designers (C#)

El designer de Windows Forms de Visual Studio genera Form1.Designer.cs con inicialización de controles auto-generada, mientras que Form1.cs contiene handlers de eventos y lógica de negocio.

Entity Framework (C#)

Las herramientas de scaffolding de EF generan partial entity classes, permitiendo a los desarrolladores agregar validación, propiedades computadas y lógica de negocio en archivos partial separados que sobreviven re-scaffolding.

ASP.NET Core Razor

Las Razor pages compilan markup (.cshtml) y code-behind (.cshtml.cs) en una única partial class, separando presentación de lógica.

Temas Avanzados

Escenario: Partial Class para Separar Responsabilidades

// C#: partial class separa una clase en multiples archivos
// File: Order.cs - Modelo principal
public partial class Order {
    public Guid Id { get; set; }
    public string CustomerEmail { get; set; }
    public List<OrderItem> Items { get; set; }
    public decimal Total { get; set; }
    public DateTime CreatedAt { get; set; }
}

// File: Order.Validation.cs - Logica de validacion
public partial class Order {
    public bool IsValid() {
        return Items.Count > 0 && Total > 0 && !string.IsNullOrEmpty(CustomerEmail);
    }
    public List<string> GetValidationErrors() {
        var errors = new List<string>();
        if (Items.Count == 0) errors.Add("Order must have items");
        if (Total <= 0) errors.Add("Total must be positive");
        if (string.IsNullOrEmpty(CustomerEmail)) errors.Add("Email required");
        return errors;
    }
}

// File: Order.Pricing.cs - Logica de precios
public partial class Order {
    public void ApplyDiscount(decimal percentage) {
        Total = Total * (1 - percentage / 100);
    }
    public void ApplyCoupon(string code) {
        var coupon = CouponService.Validate(code);
        if (coupon.IsValid) Total -= coupon.Amount;
    }
    public decimal CalculateTax(decimal rate) {
        return Total * rate;
    }
}

// File: Order.Serialization.cs - Logica de serializacion
public partial class Order {
    public string ToJson() {
        return JsonSerializer.Serialize(this);
    }
    public static Order FromJson(string json) {
        return JsonSerializer.Deserialize<Order>(json);
    }
}

Ventajas y desventajas del partial class:
  | Aspecto | Pros | Contras |
  |---------|------|---------|
  | Organizacion | Separa responsabilidades | Puede fragmentar logica |
  | Colaboracion | Multiple devs en una clase | Dificil de localizar |
  | Generacion | Code-gen separado de manual | Conflictos en merge |
  | Mantenimiento | Archivos mas pequenos | Vision fragmentada |
  | Testing | Test separado por concern | Setup repetido |

Lecciones:

• Partial class separa una clase en multiples archivos
• Ideal para separar modelo, validacion, pricing y serializacion
• C# soporta partial class nativamente; TypeScript no
• En TypeScript, usar composition o mixins en lugar de partial
• No abusar: si la clase necesita partial, quizas es demasiado grande (SRP)
• Entity Framework usa partial para separar modelo de code-gen

### Partial class esta disponible en TypeScript?

No, TypeScript no soporta partial class. Alternativas: 1) Composition: separar en clases independientes (OrderModel, OrderValidator, OrderPricer). 2) Mixins: anadir metodos via funciones. 3) Declaration merging: interfaces y namespaces se fusionan, pero no clases. 4) Extension methods: usar prototype o module augmentation. La mejor alternativa en TypeScript es composition: cada responsabilidad es una clase separada que se inyecta.