Scopo principale della programmazione ad oggetti

[misterx]

secondo voi, qual'era l'obiettivo finale degli ideatori della programmazione ad oggetti?

[lombardp]

divide et impera

[syscall]

Originally posted by "misterx"

secondo voi, qual'era l'obiettivo finale degli ideatori della programmazione ad oggetti?
Lo stesso degli ingegneri elettronici quando anni prima hanno ideato i chip..

[misterx]

Originally posted by "syscall"


Lo stesso degli ingegneri elettronici quando anni prima hanno ideato i chip..



e cioè????

[cionci]

Secondo me la modularità e la riutilizzabilità...

[misterx]

concordo appieno

qualcuno ostinatamente mi ha fornito la seguente opinione:

nato esclusivamente per lavori di gruppo

ma va là, gli ho risposto; il fatto che lo si veda come un ottimo strumento adeguato per lavori anche di gruppo è solo conseguenza di un suo sviluppo intelligente; non il suo fine :)

[cionci]

Originally posted by "misterx"

nato esclusivamente per lavori di gruppo
Da un certo punto di vista è giusto...è una conseguenza della modularità...

[misterx]

Originally posted by "cionci"


Da un certo punto di vista è giusto...è una conseguenza della modularità...


qualsiasi linguaggio se ben congegnato va bene per lavori di gruppo; basta osservare tutta la nutrita serie di DLL che negli anni sono state create e che circolano tuttora :)

[cionci]

Ok...ma la programmazione ad oggetti è stata specificamente pensata per rendere disponibile ad ogni programmatore solamente un'interfaccia con l'oggetto... Le interfacce vanno stabilite in fase di analisi e dopo devono restare le stesse... Al programmatore non importa niente se l'implementazione dei metodi o il modo di rappresentazione delle porprietà private di un oggetto cambiano... L'importante è che l'interfaccia resti la stessa... Questo favorisce notevolmente il lavoro di gruppo...

Quando si andava ad operare sulle funzioni raggruppate in moduli i parametri che le funzioni dovevano prendere spesso riguardavano dati o strutture il cui contenuto era locale al chiamante (guarda le varie API)... In questo modo l'indipendenza dai dati non c'era... Se invece si voleva operare sempre con le funzioni, ma con variaibili globali al modulo c'era comunque la possibilità che il programmatore esterno al modulo raggiungesse i dati globali compromettendo l'indipendenza da questi (senza contare che bisognava stare attenti ad operare su una sola istanza dei dati del moduli in uno spezzone di codice, guarda la funzione strtok ad esempio)...

Se l'interfaccia iniziale è progettata bene ci si mette al sicuro anche se dobbiamo modificare un oggetto (anche cambiando la rappresentazione dei dati privati)...l'importante è lasciarne l'interfaccia incariata...

Anche se si devono fare cambiamenti all'interfaccia si può evitare che anche altro codice esterno al modulo debba cambiare facendo un'oggetto di wrap sul nuovo oggetto... La nuova interfaccia del nuovo oggetto potrà poi essere sfruttata in una versione successiva del programma...

Poi non si può fare tutto con le DLL... Pensa te 100 gruppi di programmatori...ogni gruppo lavora su un modulo complesso (che magari può essere composto da diversi sottomoduli)... Fai 100 DLL ? Sarebbe il programma meno efficiente della storia ;)
Originally posted by "misterx"

qualsiasi linguaggio se ben congegnato va bene per lavori di gruppo
Ma un linguaggio ad oggetti va meglio ;)

[paxs]

tutti i buoni principi di ingegneria del software trovano il loro ambito di applicazione naturale nei linguaggi ad oggetti.
Ovviamente l'impatto si fa piu' evidente in progetti di una certa complessita'

Tra i principi che avete gia' citato (Riutilizzo e Modularita') io ne citerei un altro (secondo me importante) che e' la capacita di evolvere di un modulo (Evolvability in inglese in italiano non so)

[kingv]

Originally posted by "cionci"

Sarebbe il programma meno inefficiente della storia ;)




meno infefficiente == piu' efficiente ?? :p :p

[cionci]

Originally posted by "kingv"

meno infefficiente == piu' efficiente ?? :p :p
Mi sa che ho skazzato :D ;)