web-dev-qa-db-fra.com

Qu'est-ce qui est plus important? SOLID ou baiser?

Qu'est-ce qui est plus important? SOLID ou baiser?

Pour être cohérent avec SOLID I, je devrais injecter des classes de décorateur et de pied de page et de créer des interfaces pour eux.

public class HelloService {
   String name;
   HelloService(String name){
      this.name = name;
   }
   public String getHello() {
      Decorator decorator = new Decorator();

      String full = decorator.bar
              + this.name 
              + Footer.add(this.name);

      return full;
   }
}

public class Decorator {
    public String bar() {
        return "Some";
    }
}

public class Footer {
    public static String add(String name) {
        if (name.length() > 10) {
            return "A";
        } else {
            return "B";
        }
    }
}

Ce ne serait pas une exagération?

Mon exemple est simple, mais si c'était complexe, que dois-je faire? Si j'utilise d'autres classes en classe seulement au même endroit, devrais-je aussi les injecter?

Comment puis-je améliorer mes cours de manière à ce qu'ils soient conformes aux règles et lisibles pour tout le monde?

javaprogramming-practicesclean-codesolid
6
cimlihor

La chose la plus importante est que votre programme fonctionne et rend les utilisateurs heureux en fournissant les résultats attendus. Mais qu'est-ce qui les rendait heureux hier, pourrait ne plus être suffisant pour les garder heureux demain.

C'est pourquoi les deux principes ne sont pas en concurrence mais sont étroitement liés:

  • Kiss peut aider à se concentrer sur les résultats initiaux sans distraction, en travaillant une solution simple. En tant que bonus supplémentaire, en évitant la complexité KISS réduit le potentiel de bugs.

  • Cependant, dans les utilisateurs de la vie réelle ont tendance à changer d'avis et à ajouter des exigences nouvelles ou oublieutes pendant le développement, ne parviennent pas par la suite au cours des nombreuses années, le système sera utilisé. Si souvent, votre code doit évoluer avant que cela soit même fini. Il semble que SOLID aide à atteindre un design robuste qui peut évoluer beaucoup plus facile.

  • Parfois SOLID et KISS pourrait même se référer à la même solution

Le principal défi de l'art du développement logiciel est d'équilibrer les deux. Gardez-le aussi simple que possible, mais pas de simpeur, et en même temps, faites-le SOLID sans ajouter beaucoup de poids. En d'autres termes, n'appliquez pas les principes aveuglément.

(( PS: Votre programme n'est ni KISS ni solide: il serait beaucoup plus simple d'avoir bar() et add() comme membres de HelloService. Donc, cette solution est déjà excentrée.

ps2: Mais si vous pensez que Decorator et Footer mérite d'encapsulation Serait beaucoup plus de preuves futures à découpler les classes avec DI appropriée, de sorte que vous puissiez avoir plusieurs décorateurs et pieds de page différents (par exemple pour optimiser la mise en page en fonction du dispositif cible).

(( P.S.3: Bien entendu, ajouter DI semble disproportionné pour votre petit morceau de code. Dans le monde réel Cependant, avec des classes de complexité du monde réel, très souvent, l'effort supplémentaire de DI est proportionnellement beaucoup plus lentement.

8
Christophe

Le solide n'est pas une fin en soi, c'est n moyen d'atteindre une extrémité. Appliqué à votre exemple, cela signifie que le code AS SOLID vous en ayez besoin, pas moins. Ceci correspond également au KISS principe.

  • par exemple, si, à des fins de test de l'unité, vous devez découpler HelloService de Decorator, utilisez di. Si vous pensez que les tests fonctionnels ou d'intégration sont suffisants, vous n'en avez probablement pas besoin.

  • si vous souhaitez réutiliser HelloService, mais avec des décorateurs et des pieds de page différents, injecter ceux que le paramètre est probablement la solution la plus "simple et stupide" pour garder le code sec. S'il n'y a qu'un seul décorateur et un pied de page, vous n'avez probablement pas besoin de classes séparées pour le décorateur et le pied de page

  • si vous devez éviter d'introduire une dépendance directe entre les composants, car il fait partie d'une libération générale, et la logique de Decorator et Footer doit être fournie par un utilisateur de cette libère ( OCP), alors di sera requis

Surtout le d du SOLID est probablement la solution la plus simple pour ce type de problèmes que vous souhaitez résoudre, de sorte qu'il est parfaitement en ligne avec le baiser.

Si DI n'est pas nécessaire (encore), alors ne commencez pas l'utiliser "juste au cas où". Appliquez plutôt Yagni: Refactor à DI Dès que vous obtenez une réelle exigence pour cela.

3
Doc Brown

Appliquer des principes et des "meilleures pratiques" sans comprendre pleinement leur objectif peut être assez destructeur. La D en solide est notoire.

L'inversion de dépendance se lit sur de nombreuses "interfaces d'utilisation". Ce qui n'est pas si loin mais déclenche beaucoup beaucoup pour gifler une interface sur chaque classe qu'ils créent. Ceci n'est généralement pas utile.

Ce que cela signifie vraiment, c'est, essayez de découpler des dépendances entre A et B en introduisant une troisième entité C. Ayez ensuite A et B connaissez C, mais pas l'un à l'autre.

Cela peut être bénéfique mais comme d'autres déjà signalés, vous devez avoir un but pour cela. Si vous ne savez pas pourquoi vous le faites, s'il vous plaît ne faites pas.

Les interfaces sont les plus précieuses lorsqu'elles définissent un aspect comportemental d'une classe. C'est leur valeur primaire. Utilisez-les simplement parce que cela vous permet de tester votre code est déjà une utilisation abusive d'une interface. Cela conduit généralement à des interfaces qui possèdent une relation individuelle avec les classes qu'ils représentent, qui enfreint le principe de ségrégation à l'interface.

Cat : IScratcher, IJumper, IPettable   // helpful

Cat : ICat    // utterly useless

Donc, si vous faites cette interface ICAT pour les tests, sachez que c'est un compromis. Vous dites essentiellement "Je me fiche de la merde sur le solide, je veux juste tester ma classe".

Ce que vous devriez vraiment faire, c'est avoir des méthodes de test distinctes pour ISCRATRATER, IJUMPER et IPETTABLE.

2
Martin Maat

SOLIDE.

Le problème avec KISS est la définition de "simple" dépend de qui vous demandez. Où que votre code exemple a quelques problèmes concrets résolus avec les modèles "simples" d'interfaces et de ne pas taper le mot "statique" jamais.

Votre code sera plus long, mais pas plus compliqué avec les interfaces.

En effet, vous pouvez écrire un code plus court mais sans doute plus compliqué, peut-être une regexp? que quelqu'un avait l'habitude de regregez-vous "mais c'est si simple! Pourquoi avez-vous besoin de toutes ces classes ??"

0
Ewan