Riguardo agli schemi, spesso mi trovo nella situazione in cui non comprendo pienamente e meno apprezzo il modello finché non riesco a spiegare perché è una soluzione migliore di un modello diverso / stile in una determinata situazione.
Pertanto, vorrei presentare esempi che precisamente non usano l'iniezione delle dipendenze e consentono al pubblico di evidenziare le difficoltà concrete che questi frammenti di codice hanno (per quanto riguarda modularità, testabilità), ecc.
Come esempio concreto, mostra il codice del tipo:
def sendMessage(msg):
if len(msg) > 160:
raise MessageTooLongException('message is longer than 160 chars')
with TweetService() as tweetService: # needed to send the message
tweetService.tweet(msg, API_KEY)
Una buona risposta dovrebbe far notare che è impossibile testare questo metodo senza fare affidamento sui servizi di Twitter:
Obviously, if Twitter is down, your unit test would fail because the tweet
method raises an exception even though your code is fine. If we were using DI, we could provide a mock TweetService
object which allows to check whether the tweet
call was made and the object disposed of correctly.
Fornire esempi negativi ha il vantaggio che allena il pubblico a riconoscere tale codice mentre lo scrive e li aiuta a notare i vantaggi di DI in queste situazioni.