Les principes SOLID sont-ils vraiment solides?

Question

Le premier modèle est de cet acronyme est PRS. Voici une citation.

le principe de responsabilité unique stipule que chaque objet doit avoir un la responsabilité unique, et que la responsabilité doit être entièrement encapsulé par la classe.

C'est simple et clair jusqu'à ce que nous commençons à code ) Supposons que nous avons une classe bien définie PRS. Pour sérialiser les instances de cette classe, nous devons ajouter spécial atrributs à cette classe. Alors maintenant, la classe ont d'autres responsabilités. Ne marche pas violent SRP? Voyons une autre histoire. L'implémentation de l'Interface. Ensuite, nous mettons en œuvre une interface que nous avons simplement d'ajouter d'autres la responsabilité de dire aliéner ses resorces ou de comparer ses instances ou quoi que ce soit. Donc ma question. Est-il possible de garder PRS complet? Comment pouvons-nous le faire?

Answer 1

Je ne pense pas qu'être sérialisable ou jetable équivaut à de multiples responsabilités.

Answer 2

Eh bien, je suppose que la première chose à noter est que ce sont simplement de bons Logiciels les principes de l'Ingénierie - vous devez appliquer un jugement aussi. Donc, dans ce sens - non, ils ne sont pas solides (!)

Je pense que la question soulève le point clé - comment définissez-vous la seule responsabilité exclusive, que la classe devrait avoir?

Il est important de ne pas trop s'enliser dans des détails lors de la définition d'une responsabilité juste parce qu'une classe ne comprend beaucoup de choses dans le code dosn pas dire qu'il a beaucoup de responibilities.

Toutefois, s'il vous plaît ne rester avec elle si. Bien qu'il soit probablement impossible à appliquer dans tous les cas - c'est toujours mieux que d'avoir un seul "Dieu de l'Objet" (Anti-Pattern) dans votre code.

Si vous rencontrez des problèmes avec eux, je vous recommande de lire les suivants:

• Refactoring - Martin Fowler: Même si c'est évidemment à propos de refactoring, ce livre est aussi très utile pour l'affichage de la façon de décomposer les problèmes en logique des parties ou resposibilities - qui est la clé de la SRP. Ce livre aborde également les autres principes - cependant il le fait en beaucoup moins académique que vous pourriez avoir vu avant.

• Nettoyer le Code - Robert Martin: Qui de mieux à lire que le plus grand exposant des principes SOLIDES. Sérieusement, j'ai trouvé ce livre vraiment utile dans tous les domaines du logiciel de l'artisanat - et pas seulement les principes SOLIDES. Comme Fowler livre, ce livre est lancé à tous les niveaux de l'experiance je recommanderais donc à quiconque.

Answer 3

Afin de mieux comprendre les principes SOLIDES vous devez comprendre le problème à résoudre:

La programmation orientée objet a grandi structurés/programmation procédurale--il a ajouté un nouveau système d'organisation (classes, et al) et les comportements (polymorphisme, héritage, composition). Cela signifiait que l'OO n'a pas été séparée de structures et de procédures, mais une progression, et que les développeurs pourraient faire très procédurale OO si elles le voulaient.

Alors... SOLIDE est venu autour, comme quelque chose d'un test décisif pour répondre à la question "Suis-je vraiment en train de faire OO, ou suis-je tout simplement en utilisant les objets procéduraux?" Les 5 principes, si elle est suivie, signifie que vous êtes assez loin de la OO côté du spectre. Ne pas respecter ces règles ne signifie pas que vous ne faites pas OO, mais cela signifie beaucoup plus structurelle et procédurale OO.

Answer 4

Il y a une préoccupation légitime, car ces les sujets transversaux (sérialisation, l'exploitation forestière, la liaison de données de notification, etc.) finir en ajoutant la mise en œuvre de plusieurs classes, qui n'est là que pour appuyer certains autres sous-système. Cette mise en œuvre doit être testé, donc la classe a certainement dû se charger des responsabilités supplémentaires.

Aspect-Oriented Programming est une approche qui tente de résoudre ce problème. Un bon exemple en C# est la sérialisation, pour lequel il existe un large éventail d'attributs différents pour différents types de sérialisation. L'idée ici est que la classe ne devrait pas mettre en œuvre le code qui effectue la sérialisation, mais plutôt de déclarer comment c'est d'être sérialisé. Métadonnées est un endroit très naturel d'inclure des détails qui sont importants pour d'autres sous-systèmes, mais pas pour les tests de la mise en œuvre d'une classe.