Nella progettazione per contratto, perché le condizioni preliminari dovrebbero essere garantite da un cliente e le post-condizioni - da un fornitore?

La ragione per cui le precondizioni dovrebbero essere verificate dal cliente è che il cliente è in una posizione migliore per raccogliere o sollecitare qualsiasi informazione mancante perché (presumibilmente) è meglio in grado di comunicare con l'utente. Quando il fornitore viene coinvolto, tutto ciò che può fare è lanciare un errore e interrompere l'elaborazione, poiché non sa da dove provengano le informazioni mancanti.

Le post-condizioni dovrebbero essere gestite dal fornitore per alleviare lo sforzo richiesto per scrivere un cliente. Se il client è garantito (ad esempio) che un particolare valore non sarà mai nullo, o conterrà solo valori all'interno di un intervallo specificato, esso consentirà al client di elaborare semplicemente i valori invece di doverli prima convalidare.

Come la maggior parte delle analogie, non è universalmente applicabile. Significa davvero darti il permesso di non sentire che devi sempre controllare tutto ad ogni passo. Tuttavia, non sta dicendo che se il controllo è stato fatto una volta non dovrebbe mai essere fatto di nuovo.

Tra questi due estremi è dove entra in gioco la fiducia. Se non ti aspetti di essere chiamato da nessun'altra persona, avere fiducia nel tuo interlocutore può avere senso. Se sei una biblioteca, fidarsi del tuo chiamante è folle.

Sembra che tu stia sostenendo l'atteggiamento della biblioteca di non fidarsi mai del tuo interlocutore. I vantaggi sono la garanzia di input validi e facili da decifrare messaggi di errore. Il costo, in ordine crescente di importanza, è costituito da controlli ridondanti che influiscono su prestazioni, scrittura del codice e lettura del codice. Il peggio è concettuale.

Il pensiero di ogni limite di oggetto come limite di una biblioteca ha un costo. Io non disegno interfacce uguali su un limite di libreria come faccio all'interno dell'applicazione. È lo stesso con la convalida.

Se tutti i tuoi oggetti conducono vite interessanti, l'atteggiamento della biblioteca è valido. Ma se ho un oggetto piuttosto piccolo che è usato solo da questo chiamante, mi fido che mi perdonerai per aver assunto alcuni assegni, e alcuni lavori, sono già stati fatti.

Vale anche la pena notare che ogni oggetto dovrebbe preoccuparsi delle proprie responsabilità. È compito dei miei chiamanti darmi quello di cui ho bisogno. Ma non per decidere di cosa ho bisogno. Quindi non è ragionevole che l'aereo si aspetti che il taxi controlli le dimensioni e il peso delle tue borse nello stesso modo in cui l'aeroporto farebbe. Queste sono relazioni diverse.

Hai ragione. L'analogia non è particolarmente buona. Questo può essere parte della difficoltà con l'idea del design per contratto: è così raro nella vita reale poter contare interamente sul contratto che entrambe le parti eseguono quasi sempre i controlli pre / post / invarianti.

L'idea critica in un linguaggio di design per contratto è che, se puoi stabilire le condizioni, il compilatore può applicarle. Questo ha il vantaggio che devono essere eseguiti una volta sola e, forse più importante, i benefici che sicuramente faranno.