I fagioli di primavera dichiarati come statici sono una scelta scadente?

Question

I fagioli di primavera dichiarati come statici sono una scelta scadente?

#1 da (8 voti)

4

La domanda è piuttosto semplice, cercherò di spiegare perché voglio alcune spiegazioni.

(Tutto questo è il mio parere per sviluppatori junior di 1 anno e mezzo, che può essere più che incompleto. Ecco perché sto facendo la domanda lì) .

Aumenta l'accoppiamento tra classi, in quanto alcune classi richiedono altre classi e così via. Avere dei bean statici significherebbe chiamarli quando vuoi, senza che interferiscano effettivamente con i tuoi attributi: sarebbe come chiamare i metodi di utilità, ma sono scritti altrove.
A volte è un incubo da gestire, specialmente quando hai una configurazione orientata al xml su un progetto legacy che devi gestire.
Se hai bisogno di più dipendenze nella tua classe (ne ho una carina con qualcosa come 26 attributi che tento di fare a pezzi), vorrai ridurla a classi più piccole, ma quelle classi potrebbero aver bisogno ancora di un molti fagioli per funzionare, quindi abbatti di nuovo. Porta molta complessità alla scena.

Sto lavorando su un progetto LOC Java 70k-ish, ed è la mia prima esperienza sul campo. Sto cercando di migliorare il design di questa applicazione web e penso di aver perso i punti chiave dei bean Java con Spring.

Quindi la domanda è: sta usando classi statiche per bean una cattiva idea / un design scarso? Quale sarebbe una buona?

Domanda bonus: qualche consiglio su come decomporsi con eleganza (elegantemente?) un'applicazione Spring bean?

Grazie

PS: ho già letto su questo domanda correlata che tratta di più sugli stati delle classi / fagioli e su come evitarli, rispetto alla staticità dei fagioli come un design scarso / buono.

Modifica

(Ci scusiamo per il ritardo, non è stato possibile inserire il codice) Ecco un esempio di cosa può essere trovato e cosa mi ha fatto riflettere su questa domanda:

// 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 ...
}

La domanda riguarda i fagioli usati in molti posti diversi. Rendendoli statici si eliminerebbe la dipendenza, ma non sono sicuro di quali sarebbero le conseguenze e se si tratta di un progetto buono / cattivo.

object-oriented design java object-oriented-design spring

posta Yassine Badache 23.01.2018 - 10:02

fonte

1 risposta

Leggi altre domande sui tag object-oriented design java object-oriented-design spring

Il puntatore testa Git generalmente / di solito punta al commit ultimo / ultimo (fine) di un ramo? Versioning Javascript Files in a Web App

score 8 · Accepted Answer

Statico non è una buona idea, per molte ragioni:

Sono più difficile per prendere in giro i test unitari
Consumo di memoria permanente¹
È procedurale
E alcuni altri svantaggi

Quasi tutti gli svantaggi sopra descritti possono essere utilizzati anche per spiegare perché i fagioli statici Spring sono una cattiva idea.

It increases the coupling bewteen classes, as some classes need other classes, and so on. Having static beans would mean you call them whenever you want, without them actually interfering in your attributes: it would be like calling utility methods, but they are written elsewhere.

Se ho capito bene (non mostri alcun codice), in questo modo stai nascondendo la vera complessità delle tue classi. Questo mi ricorda il pattern Localizzatore di servizi (un anti-pattern come Singleton , infrange la legge di Demeter e anche nascondi le dipendenze). È una buona cosa esporre le dipendenze delle tue classi, perché questo espone meglio quando qualcosa di veramente brutto sta accadendo nelle dipendenze delle classi ed è più facile testarle unitamente.

It is sometimes a nightmare to manage, especially when you have an xml-oriented configuration on a legacy project that you need to manage.

Questa è la ragione per avere annotazioni al giorno d'oggi:)

If you need more dependencies in your class (I have a cute one with something like 26 attributes that I try to cut down to pieces), you would want to cut it down to smaller classes, but those classes may need still a lot of beans to function, so you cut down again. It brings a lot of complexity to the scene.

Non credo che rompere un codice grande e complesso in paci minori aggiunga complessità. Se aggiunge complessità al tuo caso, stai sbagliando :). Vi consiglio di leggere su SRP

Bonus question: any advices on how to decompose with elegance (elegantly ?) a Spring bean application ?

Un buon approccio all'utilizzo di Spring Beans è descritto qui . In generale, l'approccio migliore è utilizzare il costruttore Spring Bean per iniettare le dipendenze.

^{¹. Non è un problema con i bean Spring, perché sono Singleton di default.}