Existe-t-il des exceptions au principe SOLID?

Question

J'essaie d'appliquer les principes SOLID dans la conception de classe de mon projet. Existe-t-il des exceptions aux principes SOLID? Devons-nous appliquer ces principes de façon DÉFINITIVE? Par exemple, j'ai préparé une classe d'usine.

class XAdderFactory 
{ 
    private Person _person; 

    public bool PersonHasNoRecords 
    { 
     get 
     { 
      return string.IsNullOrEmpty(_person.HasXRecords); 
     } 
    } 

    public XAdderFactory(Person person) 
    { 
     this._person = person; 
     if (PersonHasNoRecords) 
     { 
      new XListMakerAFactory(person); 
     } 
     else 
     { 
      new XListMakerB(person); 
     } 
    } 
} 

Cette classe n'est jamais conforme à l'OCP.
De nouveaux fabricants de listes de types seront peut-être nécessaires dans le futur et je dois ajouter un nouveau bloc if if.
Mon design est-il mauvais?
Ou y a-t-il des exceptions aux principes SOLID qui ne sont pas mentionnés trop souvent?
Je ne suis pas sûr mais mon exemple est conforme à la "fermeture stratégique" d'OCP? Si vous avez d'autres exemples d'exceptions SOLID, je pense que ce serait utile pour les concepteurs.

Answer 1

Le principe ouvert-fermé est important et utile, mais il n'est pas quelque chose qui devrait être appliquée aveuglément à toutes les classes et tous les modules. Dans certains cas, la création des abstractions qui permettent l'extensibilité ne vaut pas la peine, car aucune extension n'est attendue. Dans d'autres cas, nous pouvons anticiper que les exigences changeront, mais nous ne sommes pas sûrs du type de changements à attendre, ou nous ne sommes pas sûrs des autres exigences, nous préférons donc reporter la décision et commencer par un module plus simple. mise en œuvre qui ne respecte pas OCP.

Answer 2

SOLID Les principes ne sont que des lignes directrices. Vous pouvez trouver une solution à votre problème avec ou sans utiliser ces principes.

Votre objectif principal doit être la conception d'une solution au problème plutôt que de montage de votre solution à un modèle ou d'un principe de conception spécifique.

Si vous pensez vraiment que votre classe ne doit pas être modifié, alors que la mise en œuvre Open/Closed principle. En général, je ne vois aucun problème dans la modification des classes Factory existantes pour ajouter de nouveaux types.

Ci-dessous trois principes sont vraiment utiles pour la solution la conception

Interface_segregation_principle: Aucun client ne devrait être contraint à dépendre de méthodes ne pas utiliser

Ne pas utiliser les interfaces de graisse dans votre code où les cours de mise en œuvre doivent remplacer les méthodes non utilisées ou non liées. Concevoir des interfaces granulaires et créer des classes, qui implémentent ces interfaces granulaires. question connexe SE:

Interface Segregation Principle- Program to an interface

Dependency_inversion_principle: Il est bon principe. Vous devriez programmer l'interface plutôt que l'implémentation.

Liskov_substitution_principle: Utilisez ce principe si vous avez besoin de changer votre mise en œuvre au moment de l'exécution dynamique. Si votre application ne change pas son implémentation, vous ne pouvez pas avoir besoin de cette fonctionnalité. Mais Single_responsibility_principle est discutable parmi les cinq principes. Module peut avoir une responsabilité unique, mais la conception d'une classe de restauration à une seule responsabilité conduira à des centaines/milliers de classes.

Answer 3

principes solides (ou des principes connexes) sont lignes directrices pour éviter les pièges potentiels/menaces dans un projet de logiciel en termes de mise en œuvre et de maintenance. Et juste suivre un principe aveuglément sans savoir que son reflet ne fonctionnera pas du tout.

Comme votre exemple, je vais prendre OCP. Le concept clé derrière OCP est que, si votre projet est 100% conforme à OCP, tout autre (peut être un étranger, un nouveau membre) peut faire du codage sans regarder le code actuel mais juste regarder votre documentation API (sur la méthode exposée) ce qui rend vraiment la vie de cette personne facile. Et aussi pas besoin de tester le code existant encore et encore car aucune modification ne sera apportée au code existant. Mais en effet, il y a des situations où nous devons casser l'OCP.

Ex.:

• Une nouvelle exigence (doit mettre en œuvre à l'intérieur d'une classe existante),

• Un bug-fix

• soutien-cadre limité (tout framework MVC), etc. .

Et il pourrait y avoir des situations où nous sommes en train de rompre OCP sachant que cela ne nuira pas. En ce qui concerne les principes, vous pouvez avoir une analogie simple comme celle-ci. Quand vous marchez sur la route, il y a beaucoup de principes à suivre en tant que piéton.

Ex:

• Marcher sur le côté gauche. (Pour que vous puissiez voir les véhicules entrants)

• Traversez uniquement sur un passage pour piétons (afin que les véhicules puissent vous voir clairement et qu'ils s'arrêtent).

Les suivre autant que possible définitivement vous rendre sûr. Mais imaginez une situation où il n'y a pas de véhicules sur des kilomètres, êtes-vous toujours à la recherche d'un passage pour piétons pour traverser la route? Aucun droit? Vous savez que vous êtes en sécurité même si ce n'est pas un passage pour piétons et vous traversez. Et s'il y a une situation où le côté gauche sur la route est plutôt boueux et ne peut pas marcher, serais-tu encore dans la boue juste pour suivre le principe? Aucun droit. Vous préférez marcher à droite en sachant la situation.

Je pense que vous avez une idée sur les principes. :)

Answer 4

Je pense que j'ai trouvé la première chose qui doit être considérée lors de l'écriture de codes.Il est TESTS UNIT.Solid principes, modèles de conception, etc sont des outils qui aide à faire des tests unitaires.Selon moi tout programmeur inexpérimenté (comme moi) doit appliquer les tests de l'unité sans exception. Les résultats d'essai conduisent déjà à un programmeur vers une meilleure conception.