Les classes statiques avec des méthodes statiques sont-elles considérées SOLIDES?

SOLID inclut le principe de substitution de Liskov qui a la notion que «les objets d'un programme doivent être remplaçables par des instances de leurs sous-types sans altérer l'exactitude de ce programme».

Étant donné que les classes statiques avec des méthodes statiques (un peu comme la Mathclasse) n'ont pas du tout d'instances, mon système est-il considéré comme SOLIDE si j'ai des classes statiques avec des méthodes statiques?

language-agnostic solid static-access

— Pacerier
source

Je pense que cette question est excellente. Voyons ce que la communauté a à offrir.

— Saeed Neamati

Une classe Math n'inclut pas d'état. Vous ne passez donc jamais vraiment des objets de ce type. Je ne sais donc pas en quoi cela est même pertinent.

— Martin York

Je ne pense pas que les classes statiques puissent vraiment être considérées comme étant SOLIDES pures (en grande partie pour certaines des mêmes raisons que celles déjà mentionnées), mais je les considérerais comme un excellent défenseur et outil du principe DRY.

— dreza

Comment? D'après mon expérience, la surutilisation des classes statiques a pour résultat que les gens se répètent tout le temps avec la moitié du code manipulant en permanence un objet divin statique global.

— back2dos

Je pense que je pense plus en termes de classes utilitaires pour fournir du code commun. Je suis d'accord qu'ils sont facilement et souvent mal utilisés, mais je pense toujours que le peut fournir des moyens utiles pour regrouper le code commun lorsque l'état n'est pas un problème

— dreza

Réponses:

LSP s'applique au passage d'une instance d'une classe dans une méthode, à ce que la méthode fasse quelques trucs avec cette instance et produise souvent une sorte de résultat. Cela n'a pas d'importance pour les classes statiques car en C #, vous ne pouvez pas créer d'instance d'une classe statique.

Plus important encore, les classes statiques sont scellées et ne peuvent donc pas être héritées. Cela rend votre question sans objet pour C #.

Vous pourriez dire que les classes statiques sont toujours conformes au LSP car vous ne pouvez jamais produire une sous-classe qui violerait ce principe. Vous pouvez également dire que les classes statiques ne sont jamais compatibles LSP pour la même raison.

En Java, les classes statiques sont légèrement différentes. Vous ne pouvez pas marquer une classe de niveau supérieur comme "statique", donc si vous voulez créer une classe utilitaire similaire aux classes statiques de C #, vous devez la déclarer finalet masquer son constructeur. Une fois que vous faites cela, cependant, ils se comportent de manière similaire à C # - vous ne pouvez pas les instancier ou les sous-classer. Vous pouvez déclarer une classe interne en tant que static, mais cela ne signifie pas la même chose qu'en C #: cela dénote simplement une classe de niveau supérieur imbriquée .

VB.NET se comporte exactement de la même manière que C # dans ce cas, pour autant que je sache.

Vous n'avez pas mentionné si vous êtes intéressé par les autres principes, mais je vais quand même les inclure pour être complet.

S principe de responsabilité Ingle : une classe statique suivre facilement ce principe.
O stylo / principe fermé : les classes statiques étant scellées, elles ne peuvent jamais suivre ce principe. Principe de substitution
L iskov : comme ci-dessus.
Je principe de ségrégation nterface : ne s'applique pas à une seule classe, mais diviser une grande classe statique en petits, plus spécialisés pourraient être une étape vers suivant ce principe.
D principe d'inversion de ependency :classes statiques ne peuvent pas implémenterinterfaces,sortetoute classeutilisant cela dépendra toujours demiseœuvre tout ceexiste à l'époque. Les classes statiques violent donc ce principe.

Comme les classes statiques ne satisfont pas aux 5 critères, elles ne sont pas SOLIDES.

— Adam Lear
source

car être SOLIDE signifie que nous devons satisfaire aux 5 critères, cela ne signifie-t-il pas qu'ils ne sont PAS SOLIDES?

— Pacerier

@Pacerier Oui, mais il ne faut pas essayer de chausse-pied une classe dans SOLID tout le temps si ce n'est pas nécessaire; cela dépend du contexte de la classe. Si c'est une classe utilitaire ou quelque chose, c'est correct IMO de ne pas être "SOLIDE", mais si c'est une classe de domaine réelle qui a une utilisation de domaine spécifique ...

— Wayne Molina

Je ne classerais pas une telle classe comme orientée objet et je dirais donc qu'elle ne peut pas (et ne devrait pas essayer) de répondre aux principes de la conception orientée objet.

Ces classes sont simplement une solution de contournement à l'incapacité de fournir du code en dehors d'une classe dans des langages comme Java et C #. S'ils pouvaient l'être, ils devraient être définis comme des fonctions autonomes car ils ne tirent aucun avantage de l'orientation objet.

— Gyan alias Gary Buyn
source

Je ne serais pas d'accord avec l'idée de mettre des fonctions autonomes en dehors de la classe. La capacité simple de regrouper des fonctions connexes (statiques ou non) sous un nom commun est utile pour la lisibilité. Les fonctions mathématiques conviennent parfaitement.

— jojo

@jojo D'accord. Les langages qui prennent en charge les fonctions définies en dehors des classes prennent également en charge le regroupement logique de ces fonctions, par exemple les espaces de noms en C ++.

— Gyan aka Gary Buyn

Il convient de mentionner, puisque vous n'avez spécifié aucun langage, qu'en C ++, vous pouvez passer des classes qui n'ont que des membres statiques et accéder à ces membres via un modèle, et il est donc possible de remplacer une classe avec uniquement des membres statiques, et sans doute, les méthodes appelé forme c'est "interface".

— DeadMG
source

vb.net / c # / java

— Pacerier