Newsgroup: it.comp.programmare
Titolo: [TEORIA] Legge di Demetra

<avviso>
Spero che il moderatore e il robomoderatore mi passino
questo messaggio con questo tag perchè non penso sia OT
</avviso>
[messaggio per Alex Martelli :)...ma non solo...]
Sto imparando i concetti della "Law Of Demeter" e la trovo
piuttosto interessante.
Il concetto centrale è la questione che ogni singola unità
deve conoscere l'esistenza solo delle unità strettamente
legate ad essa, per meglio dire, le unità amiche...
Questo concetto (in modo astratto) mi ricorda parecchio un
algoritmo di routing di tipo adattativo chiamato "Distance
Vector" in cui ogni router è a conoscenza dell'esistenza
solo dei nodi vicini e tramite una speciale tabella che
viene poi distribuita tra tutti i router della LAN
memorizza il numero di "passi" (la distanza) che deve
percorrere per arrivare agli altri...ma ora torniamo alla
legge di cui sopra...
Riporto quest'analogia presa da una presentazione che ho
scaricato:
"
Unit = method
closely related =
methods of class of this/self and other argument classes
methods of immediate part classes (classes that are return
types of methods of class of this/self)
"
quando scrive this/self intende il concetto di this in Java?
Un riferimento a se stessa? (la classe)
In pratica creo un metodo che ritorna una classe la quale è
la classe che contiene il metodo che ho creato...scusa i
giochi di parole ma sto esponendo i concetti cosi come mi
vengono di primo acchito.
"
Statistics from (Wilde, Matthews, Huitt, 1993): More than
half of the member functions and methods have fewer than two
C++ statements or four Smalltalk lines of code. Those tiny
methods will be generated
"
Ciò fa supporre che si creino metodi con funzionalità
semplici e tramite il principio del "closely related" si
mettano in interazione questi metodi...un pò come la
filosofia Unix (piccoli programmi/script che messi in
relazione creano un ottima piattaforma :)...insomma
un'architettura modulare..
Credo che i vantaggi di quest approccio siano riassumibili
(come fa l'autore) in quest elenco:
"
1- robustness to changes
2- shorter programs
3- design matches program
4- more understandable code
5- partially automated evolution
6- keep all benefits of OO technology
7- improved productivity
"
A mio avviso i vantaggi più rilevanti sono il primo, il
secondo e ovviamente il settimo (non trascurando il sesto..)
(ma ha qualcosa di non positivo? :)
L'autore di questo documento
(
http://www.ccs.neu.edu/research/demeter/talks/frameworks/ubs/LoD.ppt
)
prosegue andando più a fondo utilizzando come linguaggio di
supporto il Java...c'è qualche ragione particolare?
Sinceramente non ho capito molto dell'APPC...e la relazione
con i "Design Patterns"
A quanto pare ad una prima occhiata mi sembra un concetto
relazionabile all'incapsulazione nelle unità intese come
entità, giusto?
Il fatto che sia stata usata massivamente nello sviluppo del
software di controllo del Mars Pathfinder lascia capire che
questa è un ottimo approccio nel design orientato agli
oggetti (come ribadisce anche Lieberherr)
-------
scusate la prolissità di questo post ma ho tolto il freno al
mio cervello per un pò :) ma prometto che i prossimi post
saranno meno estesi.
ps. quando leggerò tutti gli altri documenti sulla LoD (mi
sembra tanto la sigla dei Legion of Doom...:) e affini ti
farò sapere
ps2. ho deciso di postare sul newsgroup perchè penso che
questo mio post possa servire...almeno spero
ps3. del link sul materiale di Robert Martin potresti
indicarmi cosa è adatto a me? (tenendo conto che io devo
ancora _imparare_ e soprattutto che vorrei finire quella
classe....); non vorrei perdermi nei meandri dell'OOA/D
(anche se so che non mi farebbe che bene, forse)
grazie
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com

</avviso>
sorry per il tag ma questo messaggio era destinato a
it.comp.lang
--
Lawrence "Rhymes" Oluyede
rhy...@myself.com
Redattore di HiT
http://hit.edengames.net

 it.comp.lang
Sarà stato anche un errore... ma a me sembra molto più in-topic
di qui...
:-)
--
Gerolamo