Llegué a la conclusión de que CreateDataFileestá haciendo una cosa al hacer una medición rápida y luego almacenar los datos, y hacer ambas cosas con el mismo método es más intuitivo para alguien que usa este código y luego tiene que hacer una medición y escribir en un archivo como llamadas a métodos separados.
Creo que este es tu problema, en realidad. El método no está haciendo una cosa. Realiza dos operaciones distintas que involucran E / S a diferentes dispositivos , y ambas se descargan a otros objetos:
- Obtener una medida
- Guarde ese resultado en un archivo en algún lugar
Estas son dos operaciones de E / S diferentes. Notablemente, el primero no muta el sistema de archivos de ninguna manera.
De hecho, debemos tener en cuenta que hay un paso medio implícito:
- Obtener una medida
- Serializar la medida en un formato conocido
- Guardar la medida serializada en un archivo
Su API debe proporcionar cada uno de estos por separado en alguna forma. ¿Cómo sabe que una persona que llama no querrá tomar una medida sin almacenarla en algún lugar? ¿Cómo sabe que no querrán obtener una medición de otra fuente? ¿Cómo sabes que no querrán almacenarlo en otro lugar que no sea el dispositivo? Hay buenas razones para desacoplar las operaciones. En un desnudo mínimo, cada pieza debe estar disponible a cualquier persona que llama. No debería ser obligado a escribir la medida en un archivo si mi caso de uso no lo requiere.
Como ejemplo, puede separar las operaciones de esta manera.
IMeasurer tiene una forma de obtener la medida:
public interface IMeasurer
{
IMeasurement Measure(int someInput);
}
Su tipo de medición podría ser algo simple, como a stringo decimal. No insisto en que necesita una interfaz o clase para ello, pero hace que el ejemplo aquí sea más general.
IFileAccess tiene algún método para guardar archivos:
interface IFileAccess
{
void SaveFile(string fileContents);
}
Entonces necesita una forma de serializar una medición. Construya eso en la clase o interfaz que representa una medida, o tenga un método de utilidad:
interface IMeasurement
{
// As part of the type
string Serialize();
}
// Utility method. Makes more sense if the measurement is not a custom type.
public static string SerializeMeasurement(IMeasurement m)
{
return ...
}
No está claro si todavía tiene esta operación de serialización separada.
Este tipo de separación mejora su API. Le permite a la persona que llama decidir qué necesita y cuándo, en lugar de forzar sus ideas preconcebidas sobre lo que debe realizar la E / S. Las personas que llaman deben tener el control para realizar cualquier operación válida , si crees que es útil o no.
Una vez que tenga implementaciones separadas para cada operación, su CreateDataFilemétodo se convierte en una abreviatura para
fileAccess.SaveFile(SerializeMeasurement(measurer.Measure()));
En particular, su método agrega muy poco valor una vez que haya hecho todo esto. La línea de código anterior no es difícil de usar para las personas que llaman directamente, y su método es puramente para mayor comodidad. Debería ser y es algo opcional . Y esa es la forma correcta de comportamiento de la API.
Una vez que se tengan en cuenta todas las partes relevantes y hayamos reconocido que el método es solo una conveniencia, debemos reformular su pregunta:
¿Cuál sería el caso de uso más común para sus llamantes?
Si el objetivo es hacer que el caso de uso típico de medir y escribir en la misma pizarra sea un poco más conveniente, entonces tiene mucho sentido que esté disponible Boarddirectamente en la clase:
public class Board : IMeasurer, IFileAccess
{
// Interface methods...
/// <summary>
/// Convenience method to measure and immediate record measurement in
/// default location.
/// </summary>
public void ReadAndSaveMeasurement()
{
this.SaveFile(SerializeMeasurement(this.Measure()));
}
}
Si esto no mejora la conveniencia, entonces no me molestaría en absoluto con el método.
Al tratarse de un método de conveniencia, surge otra pregunta.
¿Debería la IFileAccessinterfaz conocer el tipo de medición y cómo serializarlo? Si es así, puede agregar un método para IFileAccess:
interface IFileAccess
{
void SaveFile(string fileContents);
void SaveMeasurement(IMeasurement m);
}
Ahora las personas que llaman solo hacen esto:
fileAccess.SaveFile(measurer.Measure());
que es tan corto y probablemente más claro que su método de conveniencia como se concibe en la pregunta.