Stai facendo una modifica al codice, piccola, innocua. Ti fermi, sai che farai arrabbiare qualcuno. Mai provato questa sensazione? E’ esattamente ciò che prevede la legge di Hyrum:
“Non importa cosa espone un contratto,
dato un numero sufficientemente grande di utenti di un’API,
essi faranno affidamento su tutti gli aspetti osservabili del sistema esposto,
anche su quelli non esplicitati nel contratto stesso.”
Per comprenderla al meglio, analizziamo gli elementi coinvolti.
Cosa è un’API? Un’API è il confine tra utente e prodotto/servizio.
L’API di un telecomando della TV è composta dai suoi pulsanti. Essi vengono usati dagli utenti, i quali non han bisogno di sapere cosa succede all’interno del telecomando. Quel che succede all’interno del telecomando è chiamata “implementazione”. Qual’è il vantaggio di questa distinzione? Il vantaggio è che l’implementazione può cambiare senza che l’utente debba preoccuparsene.
Il contratto di un API è l’insieme di garanzie sul prodotto/servizio fornite all’utente.
Semplificando, il telecomando in questione ci garantisce di avere un pulsante di accensione e spegnimento, due pulsanti per aumentare e diminuire il volume, due pulsanti per passare al canale precedente e successivo.
Supponiamo che la prima implementazione del telecomando non abbia controlli sulla carica delle batterie. Quando la carica è bassa il telecomando continua a funzionare a patto che ci si avvicini alla ricevente. Nella seconda implementazione il telecomando smette di funzionare se la carica delle batterie è inferiore al 25%.
Anche se questi aspetti non rientrano nel contratto, con un numero sufficientemente grande di utenti, avremo il seguente scenario:
un utente della prima implementazione intuisce che se il telecomando non funziona, può avvicinarsi alla ricevente per farlo funzionare. Se il telecomando continua a non funzionare, allora deve sostituire le batterie.
Lo stesso utente, passando alla seconda implementazione si aspetta lo stesso comportamento. Se il telecomando non funziona si avvicina alla ricevente per farlo funzionare. Il telecomando però continua a non funzionare perché in questo caso l’implementazione è basata sul livello di carica e non sulla distanza dalla ricevente. L’utente conclude erroneamente che il telecomando o la ricevente non funzionino, ma non che le batterie siano scariche.
Siamo nell’ipotesi della legge di Hyrum: un utente di un’API sta facendo affidamento su un comportamento osservabile del sistema, anche se il contratto dell’API non da garanzie su di esso.
Nell’ambito dell’ingegneria del software questa legge è anche conosciuta come “Legge delle interfacce implicite”. E’ bene tenerla in considerazione durante l’evoluzione di un sistema che deve garantire retrocompatibilità. Infatti sia le modifiche al contratto (interfaccia esplicita), che quelle fatte agli altri comportamenti del sistema osservabili dagli utenti (interfaccia implicita) possono farla perdere.
E’ possibile mitigare gli effetti di questa legge in due modi: il fornitore di un API dovrebbe limitare l’esposizione di comportamenti osservabili del sistema non esplicitati nel contratto, e l’utente dovrebbe fare affidamento solo sul contratto dell’API. In questo modo sarà più facile introdurre cambiamenti in un sistema.
Top comments (0)