Contract-based design vs programmazione difensiva

Tornando alla specificazione dell’interfaccia di CardSource, è possibile notare dei commenti in formato Javadoc che specificano le precondizioni e le postcondizioni (il valore di ritorno) del metodo. Secondo il contract-based design, esiste un “contratto” tra chi implementa un metodo e chi lo chiama.

Per esempio, considerando il metodo draw(), è responsabilità del chiamante verificare il soddisfacimento delle precondizioni (“il mazzo non è vuoto”) prima di invocare il metodo. Se draw() viene chiamato quando il mazzo è vuoto ci troviamo in una situazione di violazione di contratto e può anche esplodere la centrale nucleare.

Per specificare il contratto si possono utilizzare delle asserzioni o il @pre nei commenti. Le prime sono particolarmente utili in fase di sviluppo perché interrompono l’esecuzione del programma in caso di violazione, ma vengono solitamente rimosse in favore delle seconde nella fase di deployment.

Un’altro approccio è la programmazione difensiva che al contrario delega la responsabilità del soddisfacimento delle precondizioni al chiamato, e non al chiamante.