Je suis arrivé à la conclusion que CreateDataFilefaire une chose en faisant une mesure rapide puis en stockant les données, et faire les deux dans la même méthode est plus intuitif pour quelqu'un d'autre utilisant ce code, puis devant faire une mesure et écrire dans un fichier comme appels de méthode séparés.
Je pense que c'est votre problème, en fait. La méthode ne fait rien. Il exécute deux opérations distinctes qui impliquent des E / S vers différents appareils , toutes deux déchargées sur d'autres objets:
- Récupérer une mesure
- Enregistrez ce résultat dans un fichier quelque part
Il s'agit de deux opérations d'E / S différentes. En particulier, le premier ne modifie en rien le système de fichiers.
En fait, nous devons noter qu'il y a une étape intermédiaire implicite:
- Récupérer une mesure
- Sérialiser la mesure dans un format connu
- Enregistrer la mesure sérialisée dans un fichier
Votre API doit fournir chacun de ces éléments séparément sous une forme ou une autre. Comment savez-vous qu'un appelant ne voudra pas prendre une mesure sans la stocker n'importe où? Comment savez-vous qu'ils ne voudront pas obtenir une mesure d'une autre source? Comment savez-vous qu'ils ne voudront pas le stocker ailleurs que sur l'appareil? Il y a de bonnes raisons de découpler les opérations. A un strict minimum, chaque pièce doit être disponible pour tous les appels. Je ne devrais pas être obligé d'écrire la mesure dans un fichier si mon cas d'utilisation ne l'exige pas.
Par exemple, vous pouvez séparer les opérations comme celle-ci.
IMeasurer a un moyen de récupérer la mesure:
public interface IMeasurer
{
IMeasurement Measure(int someInput);
}
Votre type de mesure peut être quelque chose de simple, comme un stringou decimal. Je n'insiste pas pour que vous ayez besoin d'une interface ou d'une classe, mais cela rend l'exemple ici plus général.
IFileAccess a une méthode pour enregistrer des fichiers:
interface IFileAccess
{
void SaveFile(string fileContents);
}
Ensuite, vous avez besoin d'un moyen de sérialiser une mesure. Construisez cela dans la classe ou l'interface représentant une mesure, ou utilisez une méthode utilitaire:
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 ...
}
On ne sait pas encore si cette opération de sérialisation est encore séparée.
Ce type de séparation améliore votre API. Il permet à l' appelant de décider de ce dont il a besoin et quand, plutôt que de forcer vos idées préconçues sur les E / S à effectuer. Les appelants doivent avoir le contrôle pour effectuer toute opération valide , que vous pensiez que c'est utile ou non.
Une fois que vous avez des implémentations distinctes pour chaque opération, votre CreateDataFileméthode devient simplement un raccourci pour
fileAccess.SaveFile(SerializeMeasurement(measurer.Measure()));
Notamment, votre méthode ajoute très peu de valeur une fois que vous avez fait tout cela. La ligne de code ci-dessus n'est pas difficile à utiliser directement par vos appelants, et votre méthode est purement pratique tout au plus. Cela devrait être et est quelque chose de facultatif . Et c'est la bonne façon pour l'API de se comporter.
Une fois que toutes les parties pertinentes ont été prises en compte et que nous avons reconnu que la méthode n'est qu'une commodité, nous devons reformuler votre question:
Quel serait le cas d'utilisation le plus courant pour vos appelants?
Si le but est de rendre le cas d'utilisation typique de mesure et d'écriture sur le même tableau un peu plus pratique, il est parfaitement logique de le rendre disponible Boarddirectement sur la classe:
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 cela n'améliore pas la commodité, je ne me soucierais pas du tout de la méthode.
Cette méthode pratique soulève une autre question.
L' IFileAccessinterface doit-elle connaître le type de mesure et comment le sérialiser? Si oui, vous pouvez ajouter une méthode pour IFileAccess:
interface IFileAccess
{
void SaveFile(string fileContents);
void SaveMeasurement(IMeasurement m);
}
Maintenant, les appelants font juste ceci:
fileAccess.SaveFile(measurer.Measure());
qui est tout aussi court et probablement plus clair que votre méthode de commodité telle que conçue dans la question.