Voy a mostrar un problema con el ejemplo. Hay una clase base con interfaz fluida:Interfaces fluidas y herencia en C#
class FluentPerson
{
private string _FirstName = String.Empty;
private string _LastName = String.Empty;
public FluentPerson WithFirstName(string firstName)
{
_FirstName = firstName;
return this;
}
public FluentPerson WithLastName(string lastName)
{
_LastName = lastName;
return this;
}
public override string ToString()
{
return String.Format("First name: {0} last name: {1}", _FirstName, _LastName);
}
}
y una clase hija:
class FluentCustomer : FluentPerson
{
private long _Id;
private string _AccountNumber = String.Empty;
public FluentCustomer WithAccountNumber(string accountNumber)
{
_AccountNumber = accountNumber;
return this;
}
public FluentCustomer WithId(long id)
{
_Id = id;
return this;
}
public override string ToString()
{
return base.ToString() + String.Format(" account number: {0} id: {1}", _AccountNumber, _Id);
}
}
El problema es que cuando se llama a customer.WithAccountNumber("000").WithFirstName("John").WithLastName("Smith")
no se puede agregar .WithId(123)
al final porque el tipo de retorno de la El método WithLastName()
es FluentPerson (no FluentCustomer).
¿Cómo se resuelve este problema habitualmente?
¡Hilo interesante!La pregunta y las respuestas dadas, que van desde la desactivación de la herencia (Ramesh), la creación de un método de extensión que convierte Person to Customer (Dzimtry), el uso interesante de Yann de Generics para la clase "base", RichardTallent dividiéndolo en dos clases separadas con campos duplicados, y los comentarios de Gorpik: todos han aumentado la convicción que tengo de que debería evitar programar con interfaces fluidas. Para mí, la "belleza" del encadenamiento de métodos no justificaría las "contorsiones del código yóguico" aquí propuestas. Pero estoy dispuesto a "comer mis palabras", como siempre :) – BillW
@BillW: tienes razón. En realidad, hice esa pregunta porque ya tengo una clase con una interfaz fluida y necesito implementar otra clase que use mucha funcionalidad de la primera clase. Un requisito más es no romper el código anterior. Creo que la interfaz fluida no es una cosa universal y puede vivir sin ella, pero en algunos casos son realmente útiles (no es necesario). Por cierto, me sorprendió la variedad de enfoques sugeridos en las respuestas también. – bniwredyc