2016-06-28 1 views
0

J'ai une classe avec deux méthodes. Pendant l'exécution de l'application, j'envoie l'instance d'Operations à une autre classe en tant que paramètre.Principe de responsabilité unique violant

public class Operations 
{ 
    /// <summary> 
    /// calculating the available money to use in operations 
    /// </summary> 
    void CalculateAvailableAmount(int x) 
    { 
     //making some calculation 
    } 

    /// <summary> 
    /// sharing some values between shareholders 
    /// </summary> 
    void Distribute(decimal total) 
    { 
     //making some calculation 
    } 
} 

après avoir écrit ci-dessus, réalisé que je devrais utiliser l'interface, parce que la logique des méthodes peut être modifiée (j'utiliser l'interface comme paramètre).

public interface IOperations 
{ 
    void CalculateAvailableAmount(int x); 
    void Distribute(decimal total); 
} 

Mais je ne peux pas décider que, ces deux méthodes ne dépend pas directement entre eux cependant, les deux faisant le calcul des valeurs et de distribuer ces valeurs. Ici, j'ai pensé que la logique des 2 méthodes peut être changée après un moment. Aussi probablement, je vais écrire plus de 10 méthodes comme ci-dessus, Est-ce violer SRP? Garder des méthodes apparentées semble une meilleure idée dans une classe mais d'autre part, je pense que cela peut aller à l'encontre du principe de la SRP. Lequel est le mieux à mettre en œuvre? toutes les méthodes dans différentes classes et différentes interfaces, ou est-ce correct?

merci

Répondre

1

Il ressemble à ce que vous êtes préoccupé par n'est pas vraiment la SRP, mais plus sur la façon d'organiser le code. Il semble que vous organisez comme des méthodes ensemble, ce qui est un bon moyen d'organisation du code. Si CalculateAvailableAmount et Distribute sont logiquement ou fonctionnellement connectés, alors il me semble. Oui, le paradigme OOP appelle souvent à des méthodes d'organisation basées sur les données sur lesquelles elles opèrent, mais l'organisation par logique ou fonction est également valide (bien que cela ne soit pas une POO).

Le principe de la responsabilité unique est un principe philosophique très nébuleux. Beaucoup de gens ont du mal à décider de la granularité ou de la grossièreté d'une seule méthode/classe/module. Ce qui suit est juste par ses propres pensées, et ce n'est en aucun cas une définition exacte, car il n'existe pas de définition exacte.

Je pense que la règle générale est de séparer le code dans son propre module si ce code a une forte chance de changer indépendamment du code environnant. Cela peut signifier une méthode ou un groupe de méthodes dans une classe, ou un bloc de code au sein d'une méthode, ou même la scission d'une bibliothèque.

Je pense qu'il y a généralement deux angles différents que vous pouvez prendre en appliquant le SRP.

Il existe l'angle YAGNI/DTSTTCPW, où vous n'appliquez pas le SRP jusqu'à ce que cela soit logique, ou jusqu'à ce que vous soyez à 100%, cela vous aidera dans le futur. Prenant votre exemple, vous exécutez en gardant ces deux méthodes dans cette même classe jusqu'à ce que vous vous rendiez compte que l'un ou plusieurs d'entre eux changent assez souvent les implémentations par rapport au code environnant. À ce moment-là, il pourrait être logique de les séparer en appliquant le SRP ... ou peut-être pas. Peut-être que conserver le code à un endroit est plus avantageux que de le fragmenter dans un autre fichier avec le SRP. Ou peut-être que vous devriez appliquer le SRP si plusieurs développeurs travaillent dans le même module. Il pourrait être logique pour SRP ce module de sorte que vous ne pas marcher sur les pieds les uns des autres ... Mais peut-être que c'est plus de séparation des préoccupations par rapport à la SRP

Ou vous pouvez venir de l'angle de conception à l'avant , et devinez quels blocs de code seront fréquemment modifiés par rapport au code environnant, et appliquer prématurément le SRP à votre base de code. J'ai un parti pris contre cette approche (surtout sur le code interne) parce que je pense que cela tend à fragmenter le code, et je trouve personnellement que le code fragmenté est plus difficile à maintenir. D'autres trouvent que de petits morceaux de code sont plus faciles à comprendre et à maintenir.

De toute façon, j'espère que cela aide un peu. Ne soyez pas trop accroché dessus. SOLID et les modèles de conception sont destinés à résoudre des problèmes. Si vous n'avez pas de problème, continuez à le garder simple.Et si vous finissez par avoir un problème, alors c'est ce que le refactoring est pour :)