Semplici domande per testare la comprensione del principio di inversione delle dipendenze

3

Sto preparando una breve presentazione (di 1-2 ore) su DIP a diversi (~ 5) sviluppatori junior (1-3 anni xp) in ufficio. Alla fine della presentazione voglio sapere se hanno capito cosa stavo presentando, quali sono alcune possibili domande che chiedo per capire la loro comprensione? Forse qualcosa che può essere risolto e spiegato da loro in 3 minuti o meno?

    
posta Louis Rhys 23.04.2013 - 09:48
fonte

3 risposte

9

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.

    
risposta data 23.04.2013 - 10:23
fonte
1

Spesso cerco di trasporre i principi dell'OOD / OOP in situazioni di vita reale, dato che l'OOP è nato in gran parte come conseguenza della necessità di infondere i modelli della vita reale nella programmazione. Non penso che DI stia mancando dalle nostre vite quotidiane. Prendi l'umile caricatore per esempio, scegli qualcuno (eccetto il caricatore dell'iPhone). La maggior parte dei produttori ha in default il fattore di forma micro-usb per i punti di ricarica. I vantaggi

  1. Per l'utente, puoi essenzialmente utilizzare qualsiasi caricabatterie con qualsiasi telefono cellulare. Confrontalo con l'iPhone e l'ultima debacle della porta di ricarica e il DI si giustifica praticamente da solo

  2. Per il produttore, una singola linea di produzione può soddisfare tutte le esigenze delle unità di ricarica dell'intera linea di prodotti.

Se i tuoi studenti riescono a trasporre adeguatamente il principio DI negli scenari della vita reale, IMO, è un buon riflesso della loro comprensione del principio

    
risposta data 24.04.2013 - 07:00
fonte
0

Potresti concentrare le tue domande di comprensione sulle conseguenze pratiche del principio DIP.

DIP si occupa di ridurre al minimo le dipendenze dalle implementazioni al fine di raggiungere un obiettivo di qualità, quindi potresti dare due piccoli progetti, uno con dipendenza di classe del client su un'interfaccia e uno con dipendenza diretta all'implementazione.

Lascia che il tuo pubblico spieghi i vantaggi dell'utilizzo di DIP in relazione a diverse qualità, ad es. testabilità o manutenibilità.

    
risposta data 23.04.2013 - 10:08
fonte