Tengo una clase C # que representa un tipo de contenido en un sistema de gestión de contenido web.
Tenemos un campo que permite que un editor de contenido web ingrese una plantilla HTML para mostrar el objeto. Básicamente utiliza la sintaxis del manillar para sustituir los valores de las propiedades del objeto en la cadena HTML:
<h1>{{Title}}</h1><p>{{Message}}</p>Desde una perspectiva de diseño de clase, ¿debo exponer la cadena HTML formateada (con sustitución) como una propiedad o método ?
Ejemplo como propiedad:
public class Example
{
private string _template;
public string Title { get; set; }
public string Message { get; set; }
public string Html
{
get
{
return this.ToHtml();
}
protected set { }
}
public Example(Content content)
{
this.Title = content.GetValue("title") as string;
this.Message = content.GetValue("message") as string;
_template = content.GetValue("template") as string;
}
private string ToHtml()
{
// Perform substitution and return formatted string.
}
}Ejemplo como método:
public class Example
{
private string _template;
public string Title { get; set; }
public string Message { get; set; }
public Example(Content content)
{
this.Title = content.GetValue("title") as string;
this.Message = content.GetValue("message") as string;
_template = content.GetValue("template") as string;
}
public string ToHtml()
{
// Perform substitution and return formatted string.
}
}No estoy seguro desde el punto de vista del diseño, ¿hace alguna diferencia o hay razones por las cuales un enfoque es mejor que el otro?
c#
design-patterns
class-design
methods
properties
Charles Wesley
fuente
fuente
Respuestas:
ACTUALIZACIÓN: Esta pregunta fue el tema de mi blog en mayo de 2014 . Gracias por la gran pregunta!
Para agregar a la respuesta de Robert Harvey : una propiedad debe ser:
lógicamente, una propiedad de la clase, la forma en que dice su color o año o modelo son las propiedades de un automóvil.
no más de, digamos, diez veces más lento de calcular que obtener de un campo.
algo que no le importa que se calcule mientras se depura. El depurador VS calcula automáticamente las propiedades.
incapaz de fallar. Los captadores siempre deben devolver un valor sin importar el estado del objeto.
No creo que su
Htmlpropiedad propuesta llegue a ninguno de esos. No lo conviertas en una propiedad a menos que los golpee a todos .fuente
ToHtmles correctamente un método, como lo ha escrito en ambos casos. Solo exponerlo públicamente.Knerd hace un buen punto: las propiedades pueden ser serializadas. Nunca deserializaría del HTML, por lo que no tiene mucho sentido convertirlo en una propiedad desde esa perspectiva.
De acuerdo con la forma en que funcionan los ORM y los objetos de repositorio: los campos en un registro o tupla se representan con propiedades, pero usted recupera el registro (o alguna forma de él) usando un método.
fuente