Legge di Demetra

Da Wikipedia, l'enciclopedia libera.

La Legge di Demetra (Law of Demeter, spesso abbreviata in LoD), nota anche come Principle of Least Knowledge ("principio della conoscenza minima") è una linea guida per lo sviluppo di software, soprattutto a oggetti. La legge fu proposta nel 1987 da un gruppo di ricercatori della Northeastern University di Boston, ed è stata in seguito ripresa e diffusa da diverse altre fonti, incluso il celebre libro The Pragmatic Programmer.[1]

Nella sua forma più generale, la LoD può essere descritta nei seguenti termini:

  • ogni unità di programma dovrebbe conoscere solo poche altre unità di programma strettamente correlate;
  • ogni unità di programma dovrebbe interagire solo con le unità che conosce direttamente.

Questi due principi possono essere riassunti col motto "non parlate con gli sconosciuti".

In programmazione a oggetti, in particolare, questo implica che un oggetto non dovrebbe interagire direttamente con (usare operazioni di) oggetti a cui accede solo indirettamente (attraverso operazioni o attributi dei suoi conoscenti diretti). Questo garantisce che un oggetto sia indipendente dalla struttura interna e dalle proprietà degli altri oggetti, compresi i loro eventuali componenti interni o le loro relazioni.

Storia della legge[modifica | modifica wikitesto]

La legge fu così chiamata perché ebbe origine all'interno del Progetto Demetra, un tentativo di utilizzo della Programmazione orientata agli oggetti. Questo progetto fu così chiamato in onore di Demetra, la dea dell'abbondanza e dell'agricoltura, come metafora della filosofia bottom-up del progetto che incarnava la legge stessa.

Legge di Demetra nell'OOP[modifica | modifica wikitesto]

Quando è applicata ai programmi scritti in un linguaggio ad oggetti, la legge di Demetra afferma che un oggetto A può richiedere un servizio (ovvero, chiamare un metodo) di un altro oggetto B ma l'oggetto A non può usare l'oggetto B per raggiungere un terzo oggetto C che possa soddisfare le sue richieste. Questo infatti implicherebbe una conoscenza dei dettagli interni di B (nello specifico, dei suoi componenti) da parte di A. Anziché consentire ad A di interagire con un oggetto ottenuto da B (uno "sconosciuto"), il progettista dovrebbe modificare la classe B in modo da fornire direttamente nell'interfaccia di B il servizio di C che serve ad A.

In modo più formale la legge di Demetra per le funzioni richiede che ogni metodo M di un oggetto O possa invocare solo i metodi dei seguenti tipi di oggetti:

  1. i propri
  2. dei suoi parametri
  3. di ogni oggetto che crea
  4. dei suoi componenti diretti

Viceversa, un oggetto dovrebbe evitare di invocare metodi di un oggetto ritornato da un altro metodo.

Motivazioni[modifica | modifica wikitesto]

Il vantaggio nel seguire la legge di Demetra consiste nel fatto che il software così creato tende ad essere più manutenibile ed adattabile. Visto che gli oggetti sono meno dipendenti dalla struttura interna degli altri oggetti, i contenitori di oggetti possono essere modificati senza dover ristrutturare i chiamanti.

Uno svantaggio della legge è che richiede la scrittura di una grande quantità di metodi wrapper per propagare le chiamate a metodo. Ciò può aumentare il tempo di sviluppo, almeno inizialmente, e sicuramente aumenta la quantità di codice necessario e peggiora le performance. Esistono comunque dei tool automatici che almeno in parte ovviano a tali problemi.

Basili et al. hanno pubblicato dei risultati sperimentali nel 1996 che suggeriscono la validità della Legge di Demetra come metodo per diminuire la probabilità della presenza di bug nel software rilasciato.

Note[modifica | modifica wikitesto]

  1. ^ Andy Hunt e Dave Thomas (1999), The Pragmatic Programmer: From Journeyman to Master, Pragmatic Programmers, LLC.

Bibliografia[modifica | modifica wikitesto]

  • V. Basili, L. Briand, W.L. Melo: A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering. October 1996. pp. 751–761. Vol. 22, Number 10.
  • Karl. J. Lieberherr, I. Holland: Assuring good style for object-oriented programs. IEEE Software, September 1989, pp 38–48.

Collegamenti esterni[modifica | modifica wikitesto]