Meilleure pratique pour une chaîne de caractères constante pour les implémentations à utiliser

Dire que j'ai une interface:

public interface IFeature
{
    Task execFeature();
}

et deux implémentations:

public class FirstFeature : IFeature
{
    private IWebApi webApi;
    public FirstFeature(IWebApi webApi)
    {
        this.webApi = webApi;
    }

    public async Task execFeature()
    {
        string response = await webApi.getClassName();
        IResult result;
        if(response==null)
            result = new TextResult("Error accessing api - check internet connection/api address");
        else
            result = new TextResult("Hello dear user – the selected class name is " + response);
        result.display();
    }
}

public class SecondFeature : IFeature
{
    private IWebApi webApi;
    public SecondFeature(IWebApi webApi)
    {
        this.webApi = webApi;
    }

    public async Task execFeature()
    {
        List<string> classNames = new List<string>();
        var classNameTasks = Enumerable.Range(1, 3).Select(i => webApi.getClassName()).ToArray();
        classNames.AddRange((await Task.WhenAll(classNameTasks)));
        IResult result;
        if (classNames[0] == null)
            result = new TextResult("Error accessing api - check internet connection/api address");
        else 
            result = new TextResult("Hello dear user – we’ve selected three new class names for you, and they are " + classNames[0] + ", " + classNames[1] + ", and " + classNames[2]);
        result.display();
    }
}

Comme vous pouvez le voir, dans les deux implémentations je avait faire la result = new TextResult("Error accessing api - check internet connection/api address"); ligne pour signaler l'erreur.

Quelle est la meilleure pratique en programmation orientée objet/une Bonne Conception de la constante error_string que je peux accéder à tous mes implémentations?

la façon dont il est maintenant, le code est dupliqué.

source d'informationauteur Ofek Agmon

c#design-patterns interface oop string

Je ne pense pas qu'il y est une meilleure pratique. C'est juste une question de préférence.

- Je stocker des constantes à l'intérieur de classes statiques.

public static class Constants
{
   public static class Messages
   {
      public const string Error = "Error accessing api...";
      public const string Hello = "Hello ...";
   }
}

Utilisation

var result = new TextResult(Constants.Messages.Error);

FYI: Certains développeurs préfèrent Enum.

6

J'ai l'habitude de faire une distinction en fonction du public visé par le message. En tant que tel, je me casse en deux catégories.

Quelle que soit la catégorie, j'évite d'écrire le même code plus d'une fois (par exemple, des chaînes de message).

Développeur Messages
- Messages affichés dans tests unitairesles messages s'affiche uniquement pendant la de débogageou des messages enregistrés à super-détaillée diagnostic fichiers
- Développeur messages nécessitent pas de localisation et doit être rédigée dans la langue de l'aménagement de la maison.
  
  Par exemple, si le développement de la société est situé à Moscou, puis il y a un argument fort pour écrire développeur des messages en russe.
  
  Dans la pratique, beaucoup de des développeurs de l'anglais.
- Options de mise en œuvre sont multiples. En général, je garde ça simple, à l'aide de champs dans une classe statique. Notez que vous pourriez avoir une classe de message pour chaque type de messages de l'écran, ou vous pourriez avoir un message central de la classe où vous regrouper plusieurs classes. Vous pourriez avoir imbriqués groupes de messages. Vous pouvez également ajouter d'autres types de constantes à utiliser dans votre code... Comme je l'ai mentionné, les options et les préférences abondent.
```
public static class FeatureMessages
{
    #region Public Fields

    public const string ApiAccessError = 
        @"Error accessing api - check internet connection/api address";
    public const string SelectedClassFormatString = 
        @"Hello dear user – the selected class name is {0}";

    #endregion
}
```
Des Messages De L'Utilisateur
- Messages affichés à l'utilisateur final. Par exemple, l'installation invitesl'utilisateur GUI menussur un avertissement à l'utilisateur boîtes de message, etc.
- Ces messages doit être localisée.
- Mise en œuvre est simple, et il faudra au moins une langue par défaut du fichier de ressources. Il ya beaucoup de ressources là-bas qui peut vous montrer comment faire cela, vous pouvez voir une explication simple ici
4

Je voudrais généralement vous recommandons d'utiliser un fichier de ressources (créé à partir des paramètres de votre projet). Vous souhaiterez peut-être fournir une sorte de wrapper si vous voulez rendre ce code plus testable.

Mettre que dans une classe statique :

internal static class ErrorMessage
{
    public const string NoAccess = "Error accessing api - check internet connection/api address";
}

Et vous pouvez faire référence qu'à l'aide de :

result = new TextResult(ErrorMessage.NoAccess);

Ou, vous pouvez utiliser un fichier de ressources.

Pas que je suis en désaccord avec @Gagner de réponse, je crois mettant Erreur et Bonjour consts qui sont logiquement liés à IFeature indépendants de classe statique pour souci d'éviter la duplication pourrait ne pas être appropriée approche. Si l'objectif est d'éviter les chevauchements alors j'aimerais réaliser de la manière suivante:

public abstract class Feature:IFeature
{
    public static readonly string Error = "Error accessing api...";
    public static readonly string Hello = "Hello ...{0}";

    protected IWebApi webApi;

    protected Feature(IWebApi webApi)
    {
        this.webApi = webApi;
    }
    public async Task execFeature()
    {
        var o = _execFeature();
        IResult result;
        if(o==null)
            result = new TextResult(Error);
        else 
            result = new TextResult( string.Format(Hello, o);
        result.display();
    }
    protected abstract object _execFeature();
}

Alors maintenant, j'ai non seulement réussi optimale de la minimisation de la duplication de code, de mettre de l'Erreur et de Salut où ils sont logiquement appartenir. Première et deuxième classes d'entités maintenant peut hériter de la classe d'entités:

public class FirstFeature:Feature
{
    public FirstFeature(IWebApi webApi):base(webApi){}

    protected override object _execFeature ()
    {
        //your code for first Feature
        //return response if no error else return null
    }
}

public class SecondFeature:Feature
{
    public SecondFeature(IWebApi webApi):base(webApi){}

    protected override object _execFeature ()
    {
        //your code for second Feature
        //return class name[0] if no error else return null
    }
}

C'est ce que ma conception de l'être.

-2

Voici un peu de code.

   namespace myNS
   {
       class MyClass
       {

           private readonly static string MyKey = "MyKey";

        //MyCode
       }
   }

-3

Outre le fait que votre fonction est l'affichage de messages, je pense qu'il ne faut pas faire, vous avez clairement un problème avec la localisation si vous mettez des messages dans votre code. N'importe où vous le tenez et la façon d'y accéder, vous ne voulez pas de recompiler pour avoir une autre langue. Vous pouvez même pas envie de le recompiler pour fixer une stupide erreur d'orthographe.

Dans votre code, utilisez les codes d'erreur. Cela peut par exemple être des enums. Puis dans votre application front-end, ont un traducteur de service (.NET a une très bonne fonctionnalité appelée "ressources" pour cela).

De cette façon, vous pouvez avoir différentes ressources pour différentes extrémités avant (comme pour le français. Ou peut-être une pour les enfants avec un langage de plus facile. Ou une technique pour les gens qui peuvent s'occuper de la vraie affaire.)

En outre, vous pouvez également avoir un système automatisé d'extrémité avant qui peut réagir à codes au lieu d'avoir à analyser les messages d'erreur et en jetant un ajustement à chaque fois que quelqu'un corrige une faute d'orthographe ou trouve un plus convivial terme pour quelque chose.

Vous devez vous connecter pour publier un commentaire.