cosa mi occorre per iniziare?

[variabilepippo]

L'approccio ad oggetti è riferibile alla programmazione "in the large" ma per quanto riguarda la programmazione "in the small" direi che ci ritroviamo sempre e comunque in campo procedurale;

Non mi sono chiari i concetti di "programmazione in the large" e "programmazione in the small"... Cosa intendi?

[sirus]

Originariamente inviato da variabilepippo

Basta dare un'occhiata a codice "C++" scritto da chi ha imparato partendo dal C, anche i professionisti tendono (è difficile scrollarsi di dosso certe abitudini) a mescolare C e C++. Non è un caso che nei più recenti testi sul C++ si proponga un approccio radicalmente diverso: partiamo dagli oggetti, poi vediamo cosa scrivere nei metodi ricordando che strutture dati e funzioni standard non vanno ricreate ogni volta da zero.

Nessuno mette in dubbio che questo sia vero ed è per questo che mi sento di sconsigliare il C++ come linguaggio di programmazione orientato agli oggetti per il semplice fatto che non "obbliga" il programmatore a pensare ad oggetti (cosa che al momento mi viene più naturale nonostante abbia avuto forti basi di programmazione procedurale).
Volendo ben vedere anche il Java non è il linguaggio più orientato agli oggetti che sia disponibile ma al contrario del C++ è già un bene che anche il più piccolo programma che si può scrivere è un micro-oggetto.

Quello che io ed immagino anche k0nt3 vogliamo dire è che anche affrontando un problema con una visione ad oggetti, la parte più "atomica" del programma sarà sempre una sequenza di istruzioni.
Prendi un esempio stupidissimo, la classe Cubo; è bello vedere il Cubo come un oggetto con il quale si può interagire tuttavia i suoi metodi (diciamo, superfice, volume e non so che altro) saranno sempre delle piccole sequenze di istruzioni che altro non possono essere che procedurali.

Originariamente inviato da variabilepippo

Non mi sono chiari i concetti di "programmazione in the large" e "programmazione in the small"... Cosa intendi?

Sono dei concetti che ho trovato su un libro (molto didattico) di programmazione orientata agli oggetti che mi sono piaciuti molti ed ho fatto miei.
Con "programmazione in the small" mi riferisco alla parte più piccola che si può trovare all'interno di un programma (tipicamente la programmazione di un metodo), mentre con "programmazione in the large" mi riferisco ad una visione più completa di tutto il programma ossia alla parte più strettamente legata alla progettazione ed all'interazione delle componenti di un programma (oggetti nel caso della nostra discussione).

[AnonimoVeneziano]

Ma uno che inizia a programmare oggi è in grado di comprendere il concetto di "Oggetto" ?

La cosa che mi preoccupa un po' è soprattutto la qualità della documentazione che si trova in giro.

La maggior parte dei tutorial / libri sull'argomento "Programmazione in [metti il tuo linguaggio OO preferito qui]" si basa quasi sempre sulla già per scontata conoscenza del paradigma procedurale e in genere si parte proprio dalla programmazione procedurale per poi introdurre il concetto di oggetto come una estensione (Il concetto della "Struct con funzioni" che , ahimè, non muore mai) . Se si vuole far partire qualcuno con la programmazione ad oggetti a mio parere bisogna anche consigliare un testo valido che orienti la sua mentalità nella direzione giusta, sennò tanto vale farlo partire col più classico C e via (come immagino abbia fatto la maggiorparte dei partecipanti a questo thread, nel bene o nel male).

Ciao

[k0nt3]

Originariamente inviato da variabilepippo

Non mi sono chiari i concetti di "programmazione in the large" e "programmazione in the small"... Cosa intendi?

l'essenza della programmazione OO sono le relazioni fra le classi, ma preso un particolare metodo di una particolare classe (cioè quello che intendevamo con "in the small") vedi praticamente programmazione procedurale (sempre considerando i tipici linguaggi a oggetti diffusi oggi*).
iniziare con la programmazione OO quindi richiede una certa visione d'insieme (tipica visione OO) e inoltre anche tutto quello che bisognava sapere per la programmazione procedurale. troppa carne al fuoco, ma sappiamo che il mondo è vario, quindi rimango sull'IMHO

* faccio sempre questa precisazione perchè ad esempio Scala è un linguaggio funzionale "in the small" e a oggetti "in the large"

[variabilepippo]

Prendi un esempio stupidissimo, la classe Cubo; è bello vedere il Cubo come un oggetto con il quale si può interagire tuttavia i suoi metodi (diciamo, superfice, volume e non so che altro) saranno sempre delle piccole sequenze di istruzioni che altro non possono essere che procedurali

Il problema sta tutto qui, io sostengo che prima si costruisce il cubo e poi si pensa a scrivere le "piccole sequenze di istruzioni" mentre voi propendete per l'approccio inverso. L'ingegnere che progetta un edificio deve fare tutta una serie di considerazioni, calcoli complessi e scelte progettuali e non si preoccupa del singolo mattoncino. D'altra parte se ci si abitua a ragionare in termini di mattoncini, al massimo si potrà costruire un'autorimessa, a meno di essere carpentieri fuori dall'ordinario.

La programmazione procedurale e quella ad oggetti sono diverse ed ovviamente la seconda richiede, nella fase FINALE, l'implementazione di routine, ma se si sceglie di seguire la strada procedurale-->oggetti si rischia di non sfruttare al massimo i vantaggi del paradigma ad oggetti (che comunque NON è la panacea propagandata da molti).

Se si vuole far partire qualcuno con la programmazione ad oggetti a mio parere bisogna anche consigliare un testo valido che orienti la sua mentalità nella direzione giusta,

Concordo, però esistono buoni libri sull'argomento, l'importante è non sceglierne uno di quelli che mescolano le carte di due mazzi diversi: il mazzo procedurale e quello ad oggetti.

[sirus]

Originariamente inviato da variabilepippo

Il problema sta tutto qui, io sostengo che prima si costruisce il cubo e poi si pensa a scrivere le "piccole sequenze di istruzioni" mentre voi propendete per l'approccio inverso. L'ingegnere che progetta un edificio deve fare tutta una serie di considerazioni, calcoli complessi e scelte progettuali e non si preoccupa del singolo mattoncino. D'altra parte se ci si abitua a ragionare in termini di mattoncini, al massimo si potrà costruire un'autorimessa, a meno di essere carpentieri fuori dall'ordinario.

Non sono d'accordo. Anche io, come tutti gli altri che hanno partecipato a questa discussione ed hanno proposto l'approccio procedurale > oggetti, vedo per prima cosa un programma nella sua interezza e solo nella fase finale vado a dare un implementazione (immancabilmente procedurale) per le parti più piccole del programma, proprio come fai tu e credo come fanno tutti coloro che programmano ad oggetti. Ma in questo caso stiamo parlando di progettazione e non propriamente di programmazione.

E' innegabile che agli inizi è difficile pensare che ci si metta a scrivere un programma che richieda un'operazione di progettazione tanto approfondita.
Non so come hai iniziato, forse i tuoi primi progetti erano molto grandi, ma quando ero agli inizi stampavo "Hello, World!" a video ed ero felice di farlo e non credo che per un programma simile sia necessario l'approccio che hai proposto a meno che ci si vada ad intestardire con inutili problemi di sovra-ingegnerizzazione.

[k0nt3]

Originariamente inviato da variabilepippo

Il problema sta tutto qui, io sostengo che prima si costruisce il cubo e poi si pensa a scrivere le "piccole sequenze di istruzioni" mentre voi propendete per l'approccio inverso. L'ingegnere che progetta un edificio deve fare tutta una serie di considerazioni, calcoli complessi e scelte progettuali e non si preoccupa del singolo mattoncino. D'altra parte se ci si abitua a ragionare in termini di mattoncini, al massimo si potrà costruire un'autorimessa, a meno di essere carpentieri fuori dall'ordinario.

ecco io penso che se prima non si impara a costruire UN mattoncino è difficile imparare a metterne in relazione molti.
secondo me mettere in relazione mattoncini è un argomento avanzato e richiede già una certa dimestichezza con la programmazione.
in effetti qui si mette in luce uno dei più grossi equivoci nella storia dell'informatica... ho sentito gente affermare che l'uomo ragiona a oggetti e quindi programmare a oggetti non richiede trasformazioni di visuale nella nostra mente
mi domando come mai qualcuno ha scoperto come funziona la nostra mente e non ha preso il nobel

[k0nt3]

Originariamente inviato da sirus

Non sono d'accordo. Io vedo per prima cosa un programma nella sua interezza (progettazione ad oggetti) e solo nella fase finale della progettazione vado a dare una specifica (immancabilmente procedurale) per le parti più piccole del programma, proprio come fai tu e credo come fanno tutti coloro che programmano ad oggetti.

implementazione forse

ps. ma ti hanno fatto usare JML? mi sembra strano visto che usi la parola "specifica" come se fosse una parola come tutte le altre

[sirus]

Originariamente inviato da k0nt3

ho sentito gente affermare che l'uomo ragiona a oggetti e quindi programmare a oggetti non richiede trasformazioni di visuale nella nostra mente

Forse non ragioniamo ad oggetti (sinceramente alle volte mi chiedo se sono o meno un essere che ragiona ) tuttavia è palese che una volta appresa la progettazione ad oggetti sia molto più semplice passare da quello che sono le nostre idee al programma vero e proprio, il salto da compiere è sicuramente inferiore rispetto a quello necessario per passare dalle nostre idee ad un programma completamente procedurale.

[sirus]

Originariamente inviato da k0nt3

implementazione forse

ps. ma ti hanno fatto usare JML? mi sembra strano visto che usi la parola "specifica" come se fosse una parola come tutte le altre

Con specifica intendevo implementazione...
Purtroppo ho anche avuto il dispiacere di utilizzare JML.

[variabilepippo]

ecco io penso che se prima non si impara a costruire UN mattoncino è difficile imparare a metterne in relazione molti.

Vedi, io ho iniziato TANTI anni fa con la programmazione procedurale (Pascal e C) e, nonostante sviluppi in Object Pascal, C#, C++, Python, ancora oggi tendo a ragionare prima in "termini sequenziali" e POI in "termini di oggetti". Questo problema è comune a molti di quelli che hanno iniziato nello stesso modo, alcuni non se ne rendono conto, altri sì.

Se potessi tornare indietro inizierei direttamente con un buon libro (anche oggi, alla fine del 2007, non sono molti) sulla OOP, indipendentemente dal linguaggio: è un problema di mentalità, una volta scavati certi "solchi" è difficile seguire un percorso diverso.

[k0nt3]

Originariamente inviato da sirus

Forse non ragioniamo ad oggetti (sinceramente alle volte mi chiedo se sono o meno un essere che ragiona ) tuttavia è palese che una volta appresa la progettazione ad oggetti sia molto più semplice passare da quello che sono le nostre idee al programma vero e proprio, il salto da compiere è sicuramente inferiore rispetto a quello necessario per passare dalle nostre idee ad un programma completamente procedurale.

si ovviamente ne sono al corrente il punto non sta tanto su come ragioniamo, ma sui vantaggi di una "visuale" rispetto all'altra. la visuale OO senza ombra di dubbio è molto adatta a mettere insieme vari tasselli, mentre la visuale procedurale è adatta a costruire i tasselli da mettere insieme. tutto qui

ps. eh JML un dispiacere? aspetta di sentire nominare alloy

[k0nt3]

Originariamente inviato da variabilepippo

Vedi, io ho iniziato TANTI anni fa con la programmazione procedurale (Pascal e C) e, nonostante sviluppi in Object Pascal, C#, C++, Python, ancora oggi tendo a ragionare prima in "termini sequenziali" e POI in "termini di oggetti". Questo problema è comune a molti di quelli che hanno iniziato nello stesso modo, alcuni non se ne rendono conto, altri sì.

Se potessi tornare indietro inizierei direttamente con un buon libro (anche oggi, alla fine del 2007, non sono molti) sulla OOP, indipendentemente dal linguaggio: è un problema di mentalità, una volta scavati certi "solchi" è difficile seguire un percorso diverso.

ho notato che è un problema abbastanza diffuso. secondo me il punto è che la programmazione procedurale non è adatta per progetti di una certa complessità strutturale e per questo motivo se una persona si trova a usare lo strumento sbagliato per lungo tempo rimane senza dubbio "segnato" da questo fatto.
ma finchè si sta imparando a programmare i programmi sono di una complessità praticamente irrilevante e quindi non penso che la programmazione OO dia molti benefici in questo caso (anzi forse confonde). certamente consiglio sempre di imparare la programmazione OO non appena si è raggiunta una certa dimestichezza con la programmazione procedurale.
ma come dicevo prima non pretendo che questo sia un metodo applicabile in generale.. è quello che credo possa adattarsi nella maggiorparte dei casi.
in tutto questo non stiamo considerando il paradigma funzionale che probabilmente è adatto a persone che vengono da una formazione più matematica, ma come il paradigma procedurale non è adatto a costruire cose di una certa complessità (dove per ora l'OOP regna incontrastata).

[fek]

Originariamente inviato da ^TiGeRShArK^

però lo stesso mi sono reso conto che imparare bene a programmare ad oggetti, soprattutto se sei partito dalla programmazione procedurale non è affatto scontato.

Esatto. Devi disimparare la maggior parte dei paradigmi che hai imparato nella programmazione procedurale e impararne di totalmente nuovi.
Imparare il paradigma procedurale e poi passare al paradigma ad oggetti e' la cosa peggiore, meglio il percorso inverso: ma l'obiettivo e' imparare entrambi i paradigmi e non solo quelli. L'obiettivo e' imparare piu' strumenti possibile, imparare quando usarli e soprattutto quando NON usarli.

Ad esempio forzare un paradigma ad oggetti per una soluzione che non lo richiede e complicare il design e' sbagliato e va evitato.

[fek]

Originariamente inviato da variabilepippo

Troppo spesso ci si illude di programmare "ad oggetti", mentre in realtà ci si limita a creare "metodi" che vengono usati come se fossero "procedure", o viceversa.

Basta dare un'occhiata a codice "C++" scritto da chi ha imparato partendo dal C, anche i professionisti tendono (è difficile scrollarsi di dosso certe abitudini) a mescolare C e C++. Non è un caso che nei più recenti testi sul C++ si proponga un approccio radicalmente diverso: partiamo dagli oggetti, poi vediamo cosa scrivere nei metodi ricordando che strutture dati e funzioni standard non vanno ricreate ogni volta da zero.

Esatto anche questo. Programmare e' complesso, quindi per un novizio l'approccio migliore e' mantenersi ad un livello di astrazione il piu' alto possibile, e imparare a descrivere la soluzione di un problema con un linguaggio il piu' possibile vicino al suo modo di pensare e piu' lontano possibile dai dettagli della macchina. Piu' aumenta la confidenza, piu' si puo' entrare nei dettagli e scendere nei livelli di astrazioni fino ad arrivare al C, ad esempio.

Inutile, ad esempio, ingolfare chi impara con concetti a basso livello come la gestione della memoria che lo distraggono dall'obiettivo che deve imparare: i meccanismi per formulare la soluzione ad un problema.

[variabilepippo]

ho notato che è un problema abbastanza diffuso.

È più diffuso di quanto si creda, spessissimo le classi vengono viste solo come "contenitori" di codice procedurale e non come entità concettualmente diverse, ciò è dovuto in parte al limitato (quando va bene) tempo che si dedica alla progettazione di una gerarchia di classi ed in parte ai "danni" derivanti dallo studio dell'approccio procedurale. Se si riesce a creare una buona struttura di classi, implementare il codice all'interno dei metodi è relativamente semplice, purtroppo non vale il viceversa.

il paradigma procedurale non è adatto a costruire cose di una certa complessità (dove per ora l'OOP regna incontrastata).

Se non sbaglio sistemi operativi, compilatori, virtual machine e tanti altri progetti di una certa complessità vengono "ancora" sviluppati in C.

[variabilepippo]

Esatto. Devi disimparare la maggior parte dei paradigmi che hai imparato nella programmazione procedurale e impararne di totalmente nuovi.
Imparare il paradigma procedurale e poi passare al paradigma ad oggetti e' la cosa peggiore, meglio il percorso inverso: ma l'obiettivo e' imparare entrambi i paradigmi e non solo quelli. L'obiettivo e' imparare piu' strumenti possibile, imparare quando usarli e soprattutto quando NON usarli.

Ad esempio forzare un paradigma ad oggetti per una soluzione che non lo richiede e complicare il design e' sbagliato e va evitato.

Quoto al 100%.

[sirus]

Originariamente inviato da variabilepippo

Se non sbaglio sistemi operativi, compilatori, virtual machine e tanti altri progetti di una certa complessità vengono "ancora" sviluppati in C.

Credo che questo sia valido per una parte di ogni progetto che hai citato. Per esempio è facile che il kernel di un sistema operativo sia scritto in C mentre tutto o quasi quello che sta sopra il kernel sia scritto in C++ o linguaggio similari.
Sui compilatori non posso dire nulla ma se ci riferiamo al solo compilatore e non all'intero IDE credo che effettivamente sia tutto scritto in C e lo stesso discorso vale per i sistemi di virtualizzazione.

[fek]

Originariamente inviato da variabilepippo

Se non sbaglio sistemi operativi, compilatori, virtual machine e tanti altri progetti di una certa complessità vengono "ancora" sviluppati in C.

In realta' no. Alcuni kernel di OS diffusi sono ancora scritti in C per questioni di compatibilita' con una larga code base legacy che non avrebbe senso convertire ad un linguaggio piu' ad alto livello.
Il kernel di Windows, ad esempio, ha ancora larghe parti in C per questione di compatibilita', ma la sua architettura e' totalmente "ad oggetti".
Per un kernel di un OS nuovo non avrebbe alcun senso scrivere in C piuttosto che in C++. BeOS era scritto in C++ ed e' tutt'oggi forse il migliore OS che abbia mai usato.

Il compiltatore C++ del VS2005 e' interamente scritto in C++ e compilato con se' stesso.

[^TiGeRShArK^]

Originariamente inviato da variabilepippo

Vedi, io ho iniziato TANTI anni fa con la programmazione procedurale (Pascal e C) e, nonostante sviluppi in Object Pascal, C#, C++, Python, ancora oggi tendo a ragionare prima in "termini sequenziali" e POI in "termini di oggetti". Questo problema è comune a molti di quelli che hanno iniziato nello stesso modo, alcuni non se ne rendono conto, altri sì.

Se potessi tornare indietro inizierei direttamente con un buon libro (anche oggi, alla fine del 2007, non sono molti) sulla OOP, indipendentemente dal linguaggio: è un problema di mentalità, una volta scavati certi "solchi" è difficile seguire un percorso diverso.

quotissimo