Design By Contract funziona per te?[Chiuso]

StackOverflow https://stackoverflow.com/questions/26455

  •  09-06-2019
  •  | 
  •  

Domanda

Utilizzi Design by Contract in modo professionale?È qualcosa che devi fare fin dall'inizio di un progetto o puoi cambiare marcia e iniziare a incorporarlo nel ciclo di vita dello sviluppo del software?Quali sono secondo te i pro/contro dell’approccio progettuale?

Mi sono imbattuto nel Progettazione per contratto approccio in un corso di scuola di specializzazione.In ambito accademico, sembrava essere una tecnica piuttosto utile.Ma al momento non utilizzo Design by Contract a livello professionale e non conosco nessun altro sviluppatore che lo utilizzi.Sarebbe bello conoscere il suo effettivo utilizzo da parte del pubblico di SO.

È stato utile?

Soluzione

Non posso raccomandarlo vivamente.È particolarmente utile se disponi di una suite che accetta le specifiche contrattuali della documentazione in linea, in questo modo:

// @returns null iff x = 0
public foo(int x) {
  ...
}

e li trasforma in unit test generati, in questo modo:

public test_foo_returns_null_iff_x_equals_0() {
  assertNull foo(0);
}

In questo modo, puoi effettivamente vedere i test che stai eseguendo, ma sono generati automaticamente.A proposito, i test generati non dovrebbero essere archiviati nel controllo del codice sorgente.

Altri suggerimenti

Puoi davvero apprezzare la progettazione per contratto quando hai un'interfaccia tra le applicazioni che devono comunicare tra loro.

Senza contratti questa situazione diventa rapidamente una partita di tennis di colpa.Le squadre continuano a respingere accuse avanti e indietro e si sprecano enormi quantità di tempo.

Con un contratto la colpa è chiara.

Il chiamante ha soddisfatto i presupposti?In caso contrario, il team del cliente deve risolverlo.

Data una richiesta valida, il destinatario ha soddisfatto le condizioni postali?In caso contrario, il team del server deve risolverlo.

Entrambe le parti hanno rispettato il contratto, ma il risultato è insoddisfacente?Il contratto è insufficiente e la questione deve essere affrontata.

Per questo non è necessario che i contratti siano attuati sotto forma di affermazioni, è sufficiente assicurarsi che siano documentati e concordati da tutte le parti.

Se esamini STL, boost, MFC, ATL e molti progetti open source, puoi vedere che ci sono così tante dichiarazioni ASSERTION e questo rende il progetto più sicuro.

Design per contratto!Funziona davvero nel prodotto reale.

Frank Krueger scrive:

Gaio:Un'eccezione Null Pointer viene generata automaticamente dal runtime, non vi è alcun vantaggio nel testare tali elementi nel prologo della funzione.

Ho due risposte a questo:

  1. Null era solo un esempio.Per quadrato(x), vorrei verificare che la radice quadrata del risultato sia (approssimativamente) il valore del parametro.Per i setter, vorrei verificare che il valore sia effettivamente cambiato.Per le operazioni atomiche, vorrei verificare che tutte le operazioni dei componenti siano riuscite o tutte fallite (in realtà un test per il successo e n test per il fallimento).Per i metodi factory in linguaggi debolmente tipizzati, voglio verificare che venga restituito il giusto tipo di oggetto.La lista potrebbe continuare all'infinito.Fondamentalmente, tutto ciò che può essere testato in una riga di codice è un ottimo candidato per un contratto di codice in un commento di prologo.

  2. Non sono d'accordo sul fatto che non dovresti testare le cose perché generano eccezioni di runtime.Semmai tu Dovrebbe testare cose che potrebbero generare eccezioni di runtime.Mi piacciono le eccezioni di runtime perché creano il sistema fallire velocemente, che aiuta il debug.Ma il null nell'esempio c'era un valore di risultato per qualche possibile input.C'è un argomento da sostenere per non tornare mai più null, ma se hai intenzione di farlo, dovresti provarlo.

È assolutamente insensato non progettare su contratto quando si fa qualcosa in ambito SOA, ed è sempre utile se si lavora su qualsiasi tipo di lavoro modulare, in cui frammenti e pezzi potrebbero essere scambiati in seguito, soprattutto se sono coinvolte scatole nere. .

Al posto di sistemi di tipo più espressivi, utilizzerei assolutamente la progettazione su contratto su progetti di livello militare.

Per i linguaggi debolmente tipizzati o con ambito dinamico (PHP, JavaScript), anche i contratti funzionali sono molto utili.

Per tutto il resto, lo metterei da parte e farei affidamento sui beta tester e sui test unitari.

Gaio:Un'eccezione Null Pointer viene generata automaticamente dal runtime, non vi è alcun vantaggio nel testare tali elementi nel prologo della funzione.Se sei più interessato alla documentazione, utilizzerei le annotazioni che possono essere utilizzate con analizzatori statici e simili (ad esempio per assicurarti che il codice non rompa le tue annotazioni).

Un sistema di tipi più forte abbinato al Design by Contract sembra essere la strada da percorrere.Dare un'occhiata a Specifica n. per un esempio:

Il linguaggio di programmazione Spec#.Spec# è un'estensione del linguaggio orientato agli oggetti C#.Estende il sistema di tipo per includere tipi non nulli e eccezioni controllate.Fornisce contratti di metodo sotto forma di pre e postcondizioni e invarianti oggetti.

Sia il test unitario che il design per contratto sono approcci di test preziosi secondo la mia esperienza.

Ho provato a utilizzare Design by Contract in un framework di test automatico del sistema e la mia esperienza è che offre flessibilità e possibilità non facilmente ottenibili dai test unitari.Ad esempio è possibile eseguire una sequenza più lunga e verificare che i tempi di risposta rientrino ogni volta che viene eseguita un'azione.

Osservando le presentazioni ad InfoQ sembra che il Design by contract sia una valida aggiunta ai convenzionali Unit test nella fase di integrazione dei componenti.Ad esempio, è possibile creare prima un'interfaccia simulata e quindi utilizzare il componente dopo o quando viene rilasciata una nuova versione di un componente.

Non ho trovato un kit di strumenti che copre tutti i miei requisiti di progettazione da progettare mediante test a contratto nella piattaforma .NET/Microsoft.

In realtà non utilizzo Design by Contract quotidianamente.So, tuttavia, che è stato incorporato nel file D lingua, come parte della lingua.

Sì, lo fa!In realtà alcuni anni fa ho progettato un piccolo framework per la convalida degli argomenti.Stavo realizzando un progetto SOA, in cui i diversi sistemi back-end eseguivano tutti i tipi di convalida e controllo.Ma per aumentare i tempi di risposta (nei casi in cui l'input non era valido e per ridurre il carico dei sistemi back-end), abbiamo iniziato a convalidare i parametri di input dei servizi forniti.Non solo per Not Null, ma anche per i pattern String.O valori all'interno degli insiemi.E anche i casi in cui i parametri avevano dipendenze tra loro.

Ora mi rendo conto che all'epoca avevamo implementato un piccolo quadro di progettazione per contratto :)

Ecco il link per chi è interessato al piccolo Convalida dell'argomento Java struttura.Che è implementato come semplice soluzione Java.

Trovo significativo che il linguaggio di programmazione Go non abbia costrutti che rendano possibile la progettazione per contratto.panico/differimento/recupero non sono esattamente questo poiché la logica di differimento e recupero consente di ignorare il panico, mentre IOW ignora il contratto interrotto.Ciò di cui abbiamo almeno bisogno è una qualche forma di panico irrecuperabile, cosa che in realtà è affermata.O, nella migliore delle ipotesi, supporto linguistico diretto della progettazione mediante costrutti contrattuali (pre e post-condizioni, implementazione e invarianti di classe).Ma data la caparbietà dei puristi del linguaggio al timone di Go Ship, non concedo alcun cambiamento a tutto ciò che è stato fatto.

È possibile implementare un comportamento simile ad un'asserzione verificando la presenza di errori di asserzione speciali nell'ultima funzione di rinvio nella funzione di panico e chiamando runtime.Breakpoint() per scaricare lo stack durante il ripristino.Per essere assertivo, quel comportamento deve essere condizionato.Ovviamente questo approccio va in pezzi quando viene aggiunta una nuova funzione di differimento dopo quella che fa asserzione.Ciò accadrà in progetti di grandi dimensioni esattamente nel momento sbagliato, con conseguenti bug mancati.

Il punto è che affermare è utile in così tanti modi che doverci girare intorno può essere un mal di testa.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top