Pregunta

Al igual que la mayoría del software, los usuarios son capaces de especificar la forma en que les gustaría manejar ciertas cosas. En mi caso, los usuarios pueden especificar qué tipo de formato que preferirían. Hay 3 opciones, licencia, caso de camellos sin formato o caja apropiada. En este momento tengo que trabajar, pero se siente muy torpe y repetitivo. Aquí está una jist de la clase.

public static class Extensions
{
    public static string GetPreferenceFormattedText(this string text, ApplicationPreferences applicationPreferences, bool pluralize)
    {
        if (applicationPreferences.FieldNamingConvention.Equals(FieldNamingConvention.SameAsDatabase))
            return text;
        string formattedText = text.Replace('_', ' ');
        formattedText = formattedText.MakeTitleCase();
        formattedText = formattedText.Replace(" ", "");

        if (applicationPreferences.FieldNamingConvention.Equals(FieldNamingConvention.Prefixed))
            return applicationPreferences.Prefix + formattedText;

        return applicationPreferences.FieldNamingConvention.Equals(FieldNamingConvention.CamelCase)
                   ? formattedText.MakeFirstCharLowerCase()
                   : formattedText;
    }
}

El método en sí no realmente se siente torpe. Es la forma en que está siendo llamado. Siempre tener que pasar las preferencias del usuario cada vez que quiera obtener el texto con formato no parece ser el mejor camino a seguir. ¿Sería mejor hacer una clase regular y aprobar la solicitud objeto preferencias a través del constructor?

Gracias.

¿Fue útil?

Solución

Una opción sería la creación de una especie de clase de fábrica, a continuación, puede crear una instancia de la clase de fábrica con o desde la instancia de la clase que contiene las preferencias.

Uso de la clase de fábrica se puede obtener una TextFormatter, la instancia del formateador devuelto dependerá de las preferencias.

Este es un ejemplo muy sencillo sólo para aclarar mi respuesta con algo de código. Esto no es muy lujoso y potencialmente puede utilizar patrones más sofisticados, pero es de esperar que el punto de partida adecuado.

Definir una interfaz y algunos formateadores

  public interface IIdentifierFormatter
  {
    string FormatText(string text);
  }

  public class UnformattedIdenifierFormatter : IIdentifierFormatter
  {
    public string FormatText(string text)
    {
      return text;
    }
  }

  public class CamelCaseIdenifierFormatter : IIdentifierFormatter
  {
    public string FormatText(string text)
    {
      // Camel case formatting here
      return text;
    }
  }

  public class ProperCaseIdenifierFormatter : IIdentifierFormatter
  {
    public string FormatText(string text)
    {
      // Proper case formatting here
      return text;
    }
  }

Ahora una clase de muestra preferencias

  enum NamingConvention 
  {
    Unformatted,
    CamelCase,
    ProperCase
  }

  public class Preferences
  {
    public NamingConvention FieldNamingConvention { get; set; }
    // .. Other settings


    // Function to get the formatter depending on the FieldNamingConvention
    public IIdentifierFormatter GetFieldNameFormatter()
    {
      switch (FieldNamingConvention)
      {
        case NamingConvention.Unformatted:
          return new ProperCaseIdenifierFormatter();
        case NamingConvention.CamelCase:
          return new ProperCaseIdenifierFormatter();
        case NamingConvention.ProperCase:
          return new ProperCaseIdenifierFormatter();          
        default:
          throw new Exception("Invalid or unsupported field naming convention.");
      }      
    }
  }

Uso del código

// Preferences loaded from some source,
// for the example I just initialized it here.      
  Preferences pref = new Preferences();
  pref.FieldNamingConvention = NamingConvention.CamelCase;

  // Get the formatter
  IIdentifierFormatter formatter = pref.GetFieldNameFormatter();

  string formatted = formatter.FormatText("the_name_to_format");
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top