Je ne suis pas sûr d'être d'accord avec cela, alors j'aimerais trouver l'article de livre ou de journal derrière cette idée afin de pouvoir vérifier que je comprends exactement ce qu'ils disent et quel contexte ils le pensent. < / p>
Je pense que je comprends l'idée - je veux juste connaître la source afin que je puisse vérifier où l'idée vient.
Pourquoi je demande:
Le terme "faire une chose" est vague et pourrait signifier beaucoup de choses, notamment "seulement avoir une méthode par classe" (ridicule) ... Je pense que cela pourrait signifier une responsabilité unique (c'est-à-dire beaucoup de méthodes.) C'est aussi Pas particulièrement utile parce que vous devez juger lorsqu'une responsabilité unique devient suffisamment compliquée pour avoir besoin de refactoriser plusieurs responsabilités avec une sorte de délégation ...
5 Réponses :
Principes solides de Bob Martin .
Principe de responsabilité unique pour être exact.
Bien que, dans la première page du chapitre sur le principe de responsabilité unique, il déclare:
Ce principe a été décrit dans le travail de Tom Demarco et de Meilir Page-Jones. Ils appelé la cohésion informatique.
Les références pour le travail qu'il a mentionné sont les suivantes:
- Spécification de l'analyse et du système structurées , Tom Demarco, Yourdon Press Computing Series, 1979
- le guide pratique de la conception des systèmes structurés , 2D. ed., Meilir Page- Jones, Yourdon Press Computing Series, 1988
Autres sources (de S.Lott dans les commentaires) incluent:
- Article Wikipedia sur Saisir
- c2 article sur Allocation de responsabilité
La liste de Martin est une collection de sources publiées précédemment.
Merci c'est génial! Je pense que l'utilisation du document de Robert Martin SRP de «raison de changement unique» est légèrement différente des «objets de la classe ne devrait faire qu'une seule chose», ce que beaucoup de gens semblent répéter. Je suis un peu inquiet que les gens puissent mal interpréter cela comme une raison de créer des classes qui ne sont qu'un groupe de "procédures" associées plutôt qu'un objet!
Bonnes liens, S. Lott. Inclus dans la réponse :)
J'ai toujours interprété «faire une chose» comme «avoir une responsabilité». Ce que cela signifie en pratique, c'est qu'un objet devrait "faire" beaucoup de choses (c'est-à-dire avoir plus d'une méthode), mais ils seront tous préoccupés par le comportement et l'état associé à une responsabilité unique.
Quelle que soit la source, je ne pense pas que ce soit une idée courante dans OO. Un objet pourrait faire beaucoup de choses.
Je pense que ça compte d'où cela vient. Je ne veux pas que la version chinoise chinoise - Je veux connaître l'intention originale bien recherchée, derrière ce qui se répète, je peux donc m'installer sur un jugement éclairé, comme les gens font dans de vraies disciplines ;-)
L'homme qui a inventé l'idée de modularité dans le logiciel était le Dr David Parnas. Le papier classique est sur les critères à utiliser dans des systèmes de décomposition dans des modules
Bien qu'il ne parle pas de OO en général (comme ce n'était pas encore autour), les idées de OO s'étendent naturellement du travail de Dr Parnas. Et une partie de ce travail est une analyse sur la manière de décomposer votre logiciel dans des modules et que les modules devraient être un seul but.
Bonne réponse - mais pas à la question spécifique que j'ai posée. ;-)
Eh bien, je crois que Parnas lui-même dit que OO n'est qu'une version moderne de son concept de modules. Donc celui qui conduit à l'autre :)
Le principe de responsabilité unique (SRP) est assez courant sur le monde de Java. Les références mentionnées ici sont bonnes.
Le principe peut s'appliquer à peu près aux classes et aux méthodes, car c'est une bonne idée pour les deux.
Les résultats d'être conscient du SRP et de l'appliquer si possible sont généralement un code plus simple plus simple, mais au coût de plusieurs classes / méthodes. Cela peut être d'une grande valeur pour la réutilisation, les tests et le prochain programmeur pour le voir.