Je sais que "la classe n'a qu'une seule raison de changer". Maintenant, qu'est-ce que c'est exactement? Y a-t-il des odeurs / signes qui pourraient indiquer que la classe n'a pas une responsabilité unique? Ou bien la vraie réponse pourrait-elle se cacher dans YAGNI et ne se reflexer que sur une seule responsabilité la première fois que votre classe change?
Réponses
Trop de publicités?Le Principe De Responsabilité Unique
Il y a beaucoup de cas évident, par exemple, CoffeeAndSoupFactory
. Du café et de la soupe dans le même appareil peut conduire à de très mauvais goût résultats. Dans cet exemple, l'appareil peut être divisé en HotWaterGenerator
et certains genre de Stirrer
. Puis un nouveau CoffeeFactory
et SoupFactory
peut être construit à partir de ces composants ainsi que des mélanges accidentels peuvent être évités.
Parmi les plus subtile cas, la tension entre les objets d'accès aux données (Dao) et les objets de transfert de données (Otd) est très fréquente. DAOs parler à la base de données, les Dto sont sérialisables pour le transfert entre les processus et les machines. Généralement DAOs besoin d'une référence à votre base de données-cadre, par conséquent, ils sont inutilisables sur vos clients riches qui n'ont ni les pilotes de base de données installé ni avoir les privilèges nécessaires pour accéder à la DB.
Odeurs De Code
Les méthodes d'une classe commence à être regroupés par domaines de fonctionnalités ("ce sont les
Coffee
méthodes et ces sont l'Soup
méthodes").La mise en œuvre de nombreuses interfaces.
Eh bien, ce principe doit être utilisé avec un peu de sel.. pour éviter de classe explosion.
Un seul la responsabilité ne se traduisent pas de méthode unique de classes. Cela signifie une seule et unique raison de l'existence... d'un service que l'objet fournit pour ses clients.
Une belle façon de rester sur la route.. l'Utilisation de l'objet en tant que personne métaphore.. Si l'objet était une personne, qui serais-je demander pour ce faire? Attribuer cette responsabilité à la classe correspondante. Cependant, vous ne demandez pas la même personne pour effectuer votre gestion des fichiers, de calculer, de salaires, d'émettre des chèques de paie, vérifier les dossiers financiers.. pourquoi voudriez-vous un seul objet pour en faire toutes ces. (son ok, si une classe a sur de multiples responsabilités en tant qu'ils sont tous liés et cohérents.)
- Si vous employez un CRC de la Carte, son une belle subtil de directive, si vous éprouvez des difficultés à obtenir toutes les responsabilités de cet objet sur un CRC de la Carte, il y a probablement d'en faire trop... un max de 7 ferait aussi un bon marqueur.
- Une autre odeur de code de la refactorisation livre serait ÉNORME Classes. Fusil de chasse à la chirurgie serait un autre... un changement d'une zone dans une classe provoque des bugs dans sans rapport avec les zones de la même classe...
- Trouver que vous apportez des modifications à la même classe à des fins différentes corrections d'erreurs encore et encore est une autre indication que la classe est trop.
Une méthode simple et pratique pour contrôler une responsabilité unique (non seulement les classes mais aussi la méthode des classes) est le choix du nom. Lorsque vous concevez une classe, si vous trouvez facilement un nom qui spécifie exactement ce qu’elle définit, vous êtes dans le bon sens. Une difficulté à choisir un nom est presque toujours un symptôme de mauvaise conception.
les méthodes de votre classe doit être cohérent....ils doivent travailler ensemble et utilisent les mêmes structures de données interne. Si vous trouvez que vous avez trop grand nombre de méthodes qui ne semblent pas totalement bien, ou semblent fonctionner sur des choses différentes, alors fort probable que vous n'avez pas un bon seule responsabilité. Souvent il est difficile de trouver des responsabilités, parfois, vous devez utiliser la classe dans plusieurs contextes différents et puis refactoriser la classe en deux classes que vous commencez à voir les distinctions. Parfois, vous trouvez que c'est parce que vous êtes un mélange d'abstrait et de concret concept ensemble, ils ont tendance à être plus difficile à voir, encore une fois, utiliser dans des contextes différents de nous aider à clarifier.