questo è chiaro, d'accordissimo con te.Citazione:
Originariamente Scritto da Mithrandir
Mi riferivo soltanto alla prolissità della sintassi :asd:, anche se l'intellisense di visual studio mi da un'ottima mano...
Visualizzazione Stampabile
questo è chiaro, d'accordissimo con te.Citazione:
Originariamente Scritto da Mithrandir
Mi riferivo soltanto alla prolissità della sintassi :asd:, anche se l'intellisense di visual studio mi da un'ottima mano...
solo io ho l'impressione che ci sia qualcosa di un lievemente ... perverso nella modellazione ad oggetti, che non solo permetta ma promuova una crescita di complessità delle interfacce non sempre giustificata?
sì e nascosta la spazzatura sotto il tappeto dell'incapsulamento, ma riemerge nel "selvaggio west" delle interfacce...
non so... mi sembra troppo aleatorio...
in realtà, mi pare che proprio l'incapsulamento e la possibilità di costruire interfacce disaccoppiate e ricche (anche troppo) siano l'unica cosa veramente riuscita nell'oo; già altre forme di disaccoppiamento richiedono non poche "alchimie", tant'è che mi sembra che i design pattern siano nati anche per fornire un libro di magie (una serie di approcci vagamente standardizzati) ed un vocabolario comune fra maghi...
il riuso del codice tramite ereditarietà l'ho sempre visto usato molto limitatamente, praticamente è raro vedere gerarchie più lunghe di 2-3 archi, inclusa la classe "foglia" delle librerie standard da cui eventualmente si deriva...
non so.... ho l'impressione che la vera ingegneria non passi di qui....
domanda da buon ingegnere, cosa intendi per "vera ingegneria"?
Intenderà ingenieria del software..
si esatto, sweng, ma in genere anche l'ingegneria in genere, quella che non ammette accrocchi inutilmente complicati e "forse funzionanti", o furbate, e che ha attenzione all'insieme del sistema e non solo al singolo dettaglio
l'oo mi sembra una soluzione locale al "casino" locale a blocchi di dati/segmenti di codice, con poca attenzione a come si combinano i pezzi risultanti nel sistema visto nel suo complesso...
non lo so, non mi convince :no: da quel che vedo le problematiche che affrontano i progetti di sviluppo e manutenzione sono esattamente le stesse sia che si usi un approccio procedurale che oo..... quindi.... esattamente, a cosa "serve" veramente?
principalmente ad assegnare competenze e responsabilità. Il vantaggio della OO è che, se progettato bene, un terzo può aprire il tuo codice e sapere cosa modifcare perchè la logica impone che una cosa sta in un determinato posto e non in un altro (o cmq i posti sono molti meno che non con la programmazione procedurale).
per come l'avevo capito io, il vantaggio avrebbe dovuto essere proprio il contrario, che un terzo non aveva bisogno di guardare il tuo codice, per usarlo e referenziarlo... (che ne è del famoso modello "black box"?)
cmq per l'ingegneria "in genere" i linguaggi di programmazione "normali" non trovano grande impiego, giacchè essa per sua natura ha la necessità di trattare un numero elevato di dati, compiendovi operazioni matematiche e statistiche che i normali linguaggi rendono assai urticanti, vista la loro pochezza in tal senso (per tacere della gestione di eventuali strumenti che questi dati leggono...).
quindi, se i calcoli sono semplici (=possiamo permetterci dei tempi di calcolo relativamente elevati) sono ottime le soluzioni tipo foglio di calcolo (Excel+vba), se i calcoli sono complessi e chiamano in causa funzioni matematiche ad alto livello (algebra matriciale, derivate di ordine n, sistemi di equazioni, etc) ci si rivolge a prodotti specifici, tipo matlab; se il punto fondamentale è l'acquisizione/controllo si va su labview.
in linea di massima le sovrastrutture che la oop offre (ma anche obbliga ad impiegare) in questi scenari sono del tutto inutili (spesso e volentieri l'insieme dei dati è unico, predeterminato e scarsamente variabile, sicchè un array tipizzato dichiarato globale è perfettamente adeguato a risolvere qualunque problema di interscambio tra le routine).
ecco, quello che mi piacerebbe trovare in un linguaggio (e che oggi come oggi c'è solo in matlab) sarebbe la capacità di eseguire operazioni matematiche anche complesse con dati anche complessi, ad esempio scrivere x=da/dt*b con x, a e b che sono matrici almeno 2d, e ottenere sia la derivata che il prodotto in modo assolutamente trasparente (senza cioè, dover creare una libreria di funzioni apposta, che è un vero delirio).
aspetta...Citazione:
Originariamente Scritto da Ronin
ci sono 2 "approcci".
Il primo approccio è quello dell'utente di un'ipotetica libreria. In questo caso è esattamente come dici tu. Il "terzo" può utilizzare le tue funzionalità in una maniera che segue la "logica" umana e non solo un grande insieme di funzioni poco correlate tra loro.
Il secondo è quello del manutentore. Se io devo prendere in gestione il tuo codice, sarà molto più facile andare a trovare la funzionalità che mi serve. Ad esempio: se devo "modificare" la funzione per sommare X giorni ad una data, nel primo caso ti basterà modificare un metodo "AddDays()" della classe "Date". Nel secondo dovrai cercare qualcosa che assomigli ad "AddDaysToDate()". Insomma... uno dei side effect della programmazione o-o è che lo trovo molto più ordinato
ADD: Matlab è in java :ouch:
Va bè, da qui a dubitare dell'effettiva utilità dell'oo ce ne passa davvero.
Il problema, come sempre in questi casi, è capire quando serve e se serve.
Serve sempre, è un modo di pensare e suddividere in unità funzionali un problema.
Assolutamente no, serve sempre è una forzatura bella e buona.
Stiamo ritornando sull'accademico? :asd:
serve per tutto ciò che va oltre l'hello world :asd:
ma non è detto che non si possa fare un hello world ad oggetti! :asd:
concordo sul serve sempre, mi sono espresso un po' laconicamente.
ma a 'sto mondo, si deve ottimizzare economicamente, giacchè i software che scriviamo servono a produrre, e non (solo) a giocarci come degli idioti, come ci piace tanto fare...
allora capita che i vantaggi nell'usarla siano insignificanti, mentre i costi dell'utilizzarla eccessivi e ingiustificabili; questi casi, che in molti campi di applicazione sono la stragrande maggioranza, meriterebbero secondo me maggiore attenzione da parte delle case produttrici di software.
@kralizek: tu prova a risolvere un sistema di equazioni alle derivate parziali con java, poi mi racconti... è chiaro che è possibile utilizzare un linguaggio standard per creare funzioni matematiche di quella complessità (altrimenti matlab nemmeno esisterebbe). il punto è che lo sforzo per riuscirci è così mostruoso da essere ingiustificato, per cui è più produttivo pagare e usare matlab.
solo che a me non serve arrivare a matlab, mi basterebbe anche molto meno e già sarei contento; ed è un peccato (o almeno io lo giudico tale) che microsoZZ o chi per lei, non trovi convenienza ad investire su di me e sulle mie esigenze.
D'accordissimo.Citazione:
Originariamente Scritto da Ronin
Allora, cominciamo a fare ordine qui, perchè non si sta facendo nessuna distinzione, in primo luogo, tra situazioni ipotetiche e realtà palpabile.
In una situazione ipotetica, sove ci sono risorse illimitate ma *soprattutto* macchine infinitamente potenti, non ha senso dire che il modello OO fallisce, anzi in questa situazione la suddivisione del programma/progetto in una miriade di sotto-unità funzionali è l'approccio migliore a qualsiasi problema, non solo nel campo della programmazione.
Se comiciamo a vedere le situazioni reali le cose cambiano, ma resta il fatto che il modello OO (in ambienti in cui ha senso che esista naturalmente) è completo e utile sempre, non tanto perchè gli oggetti siano fichi, ma perchè è un modo di pensare, come ho detto sopra, che aiuta a sezionare il problema in più sottoproblemi ed è sempre più facile risolvere 2 problemi affrontabili al posto di uno molto complesso; piuttosto, in seguito all'analisi si può pensare di sostituire le classi con moduli o sottoprogrammi topdown, o strutturati o 10 plc, sceglete voi.
La cosa che mi sembra più trasparire dalle vostre perplessità sul modello è la prassi diffusa di progettare le tipiche soluzioni a problemi di media complessità senza implementare un sistema di documentazione completo.
Nel modello OO, la cosa basilare (oltre alla comprensione delle dinamiche del modello stesso ovviamente) è programmare una documentazione curata, accessibile e a sua volta divisa in entità sempre più granulari man mano che lo schema delle classi diventa complesso. Senza questo prerequisito la riusabilità e la comprensione della gerarchia si vanno a fare benedire vanificando l'altra faccia fondamentale del modello che è la *semplicità di manutenzione*.
Per quanto riguarda la complessitàò delle interfaccie, che ho sentito nominare più di una volta, dovete tenere conto che, ipoteticamente, una buona progettazione OO no dovrebbe prevedere classi con più di una decina di metodi(ma anche meno) e campi. Il fatto è che spesso ci si trova a dover competere con tempi ristretti e modifiche in corso d'opera, ma soprattutto va tenuto conto che una gerarchia di classi molto profonda ed articolata succhia risorse HW.
Lavori con labview? :OCitazione:
Originariamente Scritto da Ronin
A che versione si è arrivati? Io ho in giro per l'emilia 3 o 4 banchi di collaudo che automatizzai con labview anni fa! che ricordi, è stato il mio primo lavoro vero :cry:
ma io col java manco l'hello world ci faccio...Citazione:
Originariamente Scritto da Ronin
volevo dire che matlab, alla fine, è scritto in java :D
esistono 2 tipi di marketing informatico:Citazione:
solo che a me non serve arrivare a matlab, mi basterebbe anche molto meno e già sarei contento; ed è un peccato (o almeno io lo giudico tale) che microsoZZ o chi per lei, non trovi convenienza ad investire su di me e sulle mie esigenze.
top-down e bottom-up.
mi spiego:
la prima "top-down" è rappresentata dalla società XXX che fa un'indagine di mercato e ne ricava che serve un programma che fa X, Y e Z. E' questo il caso di programmoni come Office o Matlab. La società lo fa, chi lo vuole se lo compra.
la seconda, "bottom-up", rappresenta invece il cliente che chiama la società e l'incarica della realizzazione del programma che fa J, K e W.
Forse tu rientri nella seconda categoria :asd:
Beh dai... una gerarchia molto articolata grava principalmente sullo stack dove sali e scendi da una procedura all'altra. E non sono sicuro che una programmazione procedurale (ovviamente non monoblocco) sia molto più leggera per lo stack. :DCitazione:
Originariamente Scritto da Aragorn
Aragorn è tutto molto bello ma la situazione ipotetica, sfortunatamente
non esiste. Pertanto :asd:
non più per fortuna... :vendetta:Citazione:
Originariamente Scritto da Aragorn
@kralizek: mi sa che io sono bottom-down :chebotta: : c'ho le mie esigenze, ma troppo pochi soldi perchè qualcuno mi dia retta...
:asd:Citazione:
Originariamente Scritto da Ronin
tralasciando che ho iniziato a programmare a 8 anni perchè mio padre a casa sua non aveva "giocattoli" e mi ha insegnato il QBASIC, nel 95 (a 13 anni), geloso dei pc fighissimi dei miei amici con windows 95, mi feci una mia "parodia" di interfaccia a finestra per il vetusto 286 scritta proprio in basic!
peccato che ho perso il source! era programmato a spaghetti (goto con la pala :asd:) ma leggeva le impostazioni da file e supportava 3 lingue (italiano inglese e francese!!!!
per oppormi al prodotto MS, lo chiama Door! :asd:
Nostalgia :frigna: :cattivo:
infatti OO e soluzione ingegneristica non sono mica sinonimiCitazione:
Originariamente Scritto da wxyz
assolutamente!
ma è un sinonimo di "soluzione ingegneristica" scegliere un "paradigma" e seguirlo in tutto e per tutto. le mezze soluzioni portano solo casini!
ma Soluzione ingenieristica non vuole dire un caxzo.
boom