it-swarm.com.de

Werden Spring Beans als statisch deklariert?

Die Frage ist ziemlich einfach, ich werde versuchen zu erklären, warum ich einige Erklärungen möchte.

(All dies ist meine 1½-jährige Junior Java Entwickler-Meinung, die mehr als unvollständig sein kann. Deshalb stelle ich dort die Frage).

  • Dies erhöht die Kopplung zwischen Klassen, da einige Klassen andere Klassen benötigen und so weiter. Wenn Sie statische Beans haben, rufen Sie sie auf, wann immer Sie möchten, ohne dass sie Ihre Attribute beeinträchtigen. Es wäre, als würden Sie Dienstprogrammmethoden aufrufen, aber sie werden an anderer Stelle geschrieben.
  • Das Verwalten ist manchmal ein Albtraum, insbesondere wenn Sie eine XML-orientierte Konfiguration für ein Legacy-Projekt haben, das Sie verwalten müssen.
  • Wenn Sie mehr Abhängigkeiten in Ihrer Klasse benötigen (ich habe eine nette mit ungefähr 26 Attributen, die ich in Stücke schneiden möchte), möchten Sie sie auf kleinere Klassen reduzieren, aber diese Klassen benötigen möglicherweise noch viele Bohnen zu funktionieren, so dass Sie wieder abschneiden. Es bringt viel Komplexität in die Szene.

Ich arbeite an einem 70.000-köpfigen LOC Java -Projekt, und es ist meine allererste Erfahrung auf diesem Gebiet. Ich versuche, das Design dieser Webanwendung zu verbessern, und ich glaube, ich habe es verpasst die wichtigsten Punkte von Java Beans mit Spring.

Die Frage ist also: Ist die Verwendung statischer Klassen für Bohnen eine schlechte Idee/ein schlechtes Design? Was wäre gut ?

Bonusfrage: Ratschläge, wie man eine Springbohnen-Anwendung elegant (elegant?) Zersetzt ?

Vielen Dank


PS: Ich habe bereits über diese verwandte Frage gelesen, das mehr über den Zustand von Klassen/Bohnen und wie man es vermeidet, als die Statizität von Bohnen als schlechtes/gutes Design behandelt.


[~ # ~] edit [~ # ~]

(Entschuldigung für die Verzögerung, Postleitzahl konnte nicht gepostet werden) Hier ist ein Beispiel dafür, was gefunden werden kann und warum ich über diese Frage nachgedacht habe:

// Bean managed in a spring-context.xml
public class HugeMapper  {

    @Autowired
    // Used here only
    private MapperBean    mapperBean;

    @Autowired
    // Used here only
    private ServiceBean   serviceBean;

    @Autowired
    // Used in a couple of classes
    private UtilitaryBean utilitaryBean;

    @Autowired
    // Used in a couple of beans
    private UsefulBean    usefulBean;

    @Autowired
    // Used in nearly half the components
    private OverusedBean  overUsedBean;

    // Code treatment ...
}

Die Frage betrifft die Bohnen, die an vielen verschiedenen Orten verwendet werden. Wenn Sie sie statisch machen, wird die Abhängigkeit beseitigt, aber ich bin mir nicht sicher, welche Konsequenzen dies haben würde und ob es sich um ein gutes/schlechtes Design handelt.

5
Yassine Badache

Statik ist aus vielen Gründen keine gute Idee:

Fast jeder der oben genannten Nachteile kann auch verwendet werden, um zu erklären, warum statische Spring Beans eine schlechte Idee sind.

Dies erhöht die Kopplung zwischen Klassen, da einige Klassen andere Klassen benötigen und so weiter. Wenn Sie statische Beans haben, rufen Sie sie auf, wann immer Sie möchten, ohne dass sie Ihre Attribute beeinträchtigen. Es wäre, als würden Sie Dienstprogrammmethoden aufrufen, aber sie werden an anderer Stelle geschrieben.

Wenn ich das richtig verstehe (Sie zeigen keinen Code), verbergen Sie auf diese Weise die wahre Komplexität Ihrer Klassen. Dies erinnert mich an das Service Locator-Muster (ein Anti-Muster wie Singleton, bricht das Gesetz von Demeter und auch verstecken die Abhängigkeiten). Es ist eine gute Sache, die Abhängigkeiten Ihrer Klassen verfügbar zu machen, da dies besser verfügbar ist, wenn etwas wirklich Schlimmes in Bezug auf die Klassenabhängigkeiten passiert und es einfacher ist, sie einem Komponententest zu unterziehen.

Die Verwaltung ist manchmal ein Albtraum, insbesondere wenn Sie eine XML-orientierte Konfiguration für ein Legacy-Projekt haben, das Sie verwalten müssen.

Dies ist der Grund, heutzutage Anmerkungen zu haben :)

Wenn Sie mehr Abhängigkeiten in Ihrer Klasse benötigen (ich habe eine nette mit ungefähr 26 Attributen, die ich in Stücke schneiden möchte), möchten Sie sie auf kleinere Klassen reduzieren, aber diese Klassen benötigen möglicherweise noch viele Bohnen zu funktionieren, so dass Sie wieder abschneiden. Es bringt viel Komplexität in die Szene.

Ich denke nicht, dass das Brechen eines großen und komplexen Codes in kleinen Schritten die Komplexität erhöht. Wenn es in Ihrem Fall die Komplexität erhöht, machen Sie das falsch :). Ich empfehle über SRP zu lesen

Bonusfrage: Gibt es Ratschläge, wie man eine Springbohnenanwendung mit Eleganz (elegant?) Zersetzt?

Ein guter Ansatz für die Verwendung von Spring Beans wird beschrieben hier . Im Allgemeinen ist es am besten, den Spring Bean-Konstruktor zu verwenden, um die Abhängigkeiten einzufügen.

¹. Kein wirkliches Problem mit Spring Beans, da sie standardmäßig Singleton sind.

8
Dherik