Primo, la creazione di oggetti correlati delle classi può effettivamente essere effettuata da nuovi. Tuttavia, quando il progetto è troppo grande e l'oggetto ha troppe dipendenze, dobbiamo scrivere molto nuovo codice durante la costruzione dell'oggetto, e potrebbe esserci un metodo per chiamare direttamente l'oggetto dopo aver dimenticato di istanziare alcuni oggetti dipendenti, allora ci sarà un'eccezione per il puntatore nullo. Se questo processo viene lasciato alla gestione dei container, non dobbiamo preoccuparci dell'istanziazione degli oggetti, e non ci saranno eccezioni di null pointer quando si usano oggetti dipendenti in qualsiasi momento, e il codice può essere semplificato.
In secondo luogo, gli attributi usati nel processo di chiamata del metodo possono essere attributi di istanza; se sono tutti definiti come statici, che dire dei dati usati nel metodo? Se definisci tutti i metodi come statici, allora le proprietà della classe a cui si fa riferimento nel metodo devono essere definite come statiche, che equivale agli attributi globali, quindi sicuramente ci saranno problemi di sincronizzazione dei dati.
In effetti, ha senso riflettere sui principi di programmazione dati nel design pattern, tutti volti a costruire codice altamente leggibile, facile da mantenere e scalabile. I miei migliori auguri!
È comodo assemblare software tramite blocchi da costruzione, ed è comodo creare software con alta coesione e basso accoppiamento (estraendo dipendenze dal codice)
Sviluppo collaborativo, debug del codice (non è necessario integrare i componenti, possono essere testati separatamente) e il codice creato è più robusto.
Lo sviluppo del progetto presta attenzione ad alta coesione e basso accoppiamento, e l'uso dell'iniezione di dipendenza può evitare l'uso della nuova area di parole chiave per creare oggetti, riducendo così l'accoppiamento tra classi
|
Pubblicato su 10/02/2019 18:14:29
|
|
|
