Necessità di interfacce, iniezioni in un progetto unico

Question

Perché dovrei implementare Interfaces and Dependency Injection su un sito senza quasi nessuna possibilità di riutilizzo o aggiornamento da parte di chiunque altro?

Answer 1

Quando hai imparato a programmare un computer, stavi sviluppando una sorta di "memoria muscolare" del tuo mestiere. Nel corso degli anni, continui a programmare nella stessa mentalità. La maggior parte delle persone non impara fin dall'inizio tutti i nobili principi OOP, quindi sembra che facciano più sforzo del modo in cui hanno imparato.

Dovresti prendere l'abitudine di usare le tecniche di progettazione OOP ogni volta che usi un linguaggio OOP, perché questo ti renderà uno sviluppatore migliore nel complesso. Il tuo obiettivo dovrebbe essere quello di riqualificare la memoria muscolare della programmazione per usare quelle tecniche. Quindi non dovrai porre queste domande e presumere che le tecniche stiano in qualche modo "ostacolando" la tua programmazione. Diventi un programmatore che programma in quel modo.

Answer 2

Rende spesso il test delle unità un po 'più semplice. Ad esempio, potresti avere un tipo che utilizza un altro tipo che si collega a un database. Per i test unitari del primo tipo, è possibile iniettare un mock test al posto del secondo tipo, consentendo di testare efficacemente il primo tipo senza collegarsi indirettamente al database tramite il secondo tipo.

Answer 3

Perché, in effetti?

Non credo che le interfacce e l'iniezione riguardino solo il riutilizzo o l'aggiornamento.

Personalmente, utilizzo interfacce e DI per tutti i progetti. Non è sufficiente un sovraccarico per rendere loro un vantaggio.

Answer 4

Perché il presupposto che stai facendo è lo stesso presupposto che ha portato a Y2K.

Answer 5

Trovo che sia molto più semplice riutilizzare il mio codice in modi a cui non avevo ancora pensato. Inoltre, semplifica la modifica del funzionamento del codice senza modificare il codice sorgente.

Sto usando Spring.NET per l'iniezione di dipendenza.

Supponiamo che tu abbia una classe Machine che ha una funzione DoWork (). Quindi si crea un'interfaccia IWorkAlgorithm, con implementazioni di algoritmi specifici per ogni macchina.

In ogni istanza di Machine è stato inserito un IWorkAlgorithm e Machine.DoWork () chiama l'implementazione iniettata.

Ora hai i seguenti vantaggi:

1. Puoi scambiare nuove implementazioni semplicemente modificando un file XML.
2. È possibile modificare le proprietà di ciascuna implementazione (timeout, limiti, ecc.) modificando un file XML.
3. Puoi riutilizzare le tue implementazioni al di fuori della classe Machine.

Answer 6

Se stai eseguendo una programmazione orientata agli oggetti, anche se sei l'unico sviluppatore che esaminerà il codice, dovresti comunque essere test unitario e questo diventa complicato se non usi l'iniezione di dipendenza.

Non dimenticare che l'altro " altro sviluppatore " sul tuo software puoi davvero essere tu. Puoi mettere insieme una massa di codice altamente accoppiato e interdipendente che funziona e persino capirlo mentre ci stai lavorando, ma nel momento in cui ti allontani dal progetto, anche per un paio di giorni, inizierai dimenticare tutte le piccole cose che hanno impedito al gomitolo di sfaldarsi.

Quando torni ad esso (e devo ancora vedere un software che non ha richiesto alcune modifiche lungo la strada), ti augurerai di aver seguito tutte le migliori pratiche.