I'm learning the java Spring framework.
Le mie congratulazioni e condoglianze.
So far, I understood that Spring will make stuff transparent with its configurations so that IoC and Factory are not too complicated to implement
Bene, no. Spring incoraggia Iniezione di dipendenza , che può essere una buona cosa. Ma non hai bisogno di Spring to do Dependency Injection.
Con Spring ciò che ottieni sono tante annotazioni @autowired diffuse nel tuo codice che ora sono irrimediabilmente accoppiate al framework, o tutto il tuo codice di root di composizione (solitamente principale) spostato in un file xml.
Le annotazioni nascondono fondamentalmente il fatto che stai programmando in una nuova lingua ora. Sta seguendo una filosofia chiamata convenzione sulla configurazione , che funziona fintanto che tutto procede come previsto. Se non ti dispiace non essere in grado di assumere semplici programmatori Java ma ora devi assumere programmatori Java / Spring, quindi va bene. Ma queste cose ti uniscono irrimediabilmente al quadro. Se questo ti preoccupa, considera di scrivere POJO .
Lo spostamento del codice main in un file xml offre una chiara separazione tra codice di costruzione e codice di comportamento. La separazione è una buona cosa e funziona bene con il POJO, ma avresti potuto lasciarlo in main e fare la separazione a mano se ti fidi solo di non mescolare costruzione e comportamento quando sono espressi nella stessa lingua. Se hai bisogno di questa separazione imposta bene, ma potresti imparare a non fare un casino diffondendo new dappertutto. new è più a casa in un contesto statico. I POJO sono i migliori, senza nemmeno sapere che esistono metodi statici.
Ecco un modello di progettazione per fare questo:
static void main() {
//Construct many objects and "wire" them together using dependency injection
String greetee = "world"; // <- A dependency
Greeter greeter = new Greeter(greetee); // <- An injection
//Start the object graph ticking by calling only one method.
greeter.greet(); // All behavior for this program happens now
}
Puoi costruire molti oggetti in questo modo e connetterli in modi meravigliosi. Non deve essere piatto. Puoi usare qualsiasi modello di creazione che ti piace fare la tua costruzione. Quello che non dovresti fare è mescolare qualsiasi comportamento di logica aziendale in quella parte del tuo codice. Dovremmo vedere il comportamento solo quando eseguiamo l'ultima riga di main. A questo punto siamo fuori dal contesto statico.
Spring e la maggior parte di tutti i framework DI utilizzano questo modello. Assorbe semplicemente il cablaggio dei "molti oggetti" in una chiamata di fabbrica che legge un file xml. Se pensi che sia più facile dell'uso dei costruttori java o dei modelli creativi,
L'IoC è un principio importante da comprendere. Usare semplicemente Spring non ti farà capire e in realtà non fa nulla per aiutarlo a implementarlo.
Inversion of Control (IoC) non costringe il codice di alto livello a dipendere direttamente dal codice di basso livello. Ciò consente di modificare i dettagli di basso livello senza influire sul codice di alto livello o l'un l'altro. Essere in grado di cambiare è ciò che rende il software morbido.
IoC lo fa facendo dialogare un oggetto con un altro attraverso il polimorfismo. Alcuni chiamano questo Tell, non chiedere . Il punto è che non dovresti sapere con cosa stai parlando.
Now I have coded A LOT but I have never thought of organizing my code based on design patterns...
Modelli di design non sono tanto un modo di organizzare il codice quanto uno schema ricorrente per risolvere i problemi in lingue che non possono risolvere banalmente questi problemi. Non sono una buona pratica né un principio di progettazione. Sono solo cose che succedono, molto. Quindi abbiamo dato loro un nome per rendere più facile parlarne. I pattern non sono sempre cose buone nel senso del design ; se stai cercando di usarli per progettare i tuoi programmi invece di trattarli come strumenti che risolvono determinati problemi specifici, allora stai sbagliando.
IoC è un principio di progettazione (non un modello). Richiede qualche forma di polimorfismo. Alcuni modelli ti danno diversi tipi di polimorfismo. Ad esempio il modello di strategia e il modello di modello ti danno entrambi il polimorfismo. Il primo anche se composizione e delegazione. Il secondo attraverso l'ereditarietà. Non sono un fan del secondo.
Gioca con Spring e scopri cosa fa per te. Decidi tu se hai davvero bisogno di ciò che offre. L'ho visto pulire il codice. Ho visto codice pulito che non ne ha bisogno. È davvero una questione su chi stai codificando.